RFC 7375

Secure Telephone Identity Threat Model

📅 published October 2014, from ietf

Secure Telephone Identity Threat Model 📞✨

Title block, bestie 💖

  • RFC number: 7375
  • Authors: J. Peterson, NeuStar, Inc. 🎀
  • Category: Informational 🌸
  • Date: October 2014 📅
  • Stream: Internet Engineering Task Force (IETF) 🦋
  • ISSN: 2070-1721
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates, so it stands on its own 🧚

Abstract 🌸

Okay so the Internet and the telephone network have gotten super tangled together, and that means attackers can fake or hide calling party numbers to run bulk commercial calling schemes, hack voicemail boxes, or even get around the multi-factor authentication that banks trust. 😭 This doc is the threat analysis for that whole mess: it lists the actors, looks at what attackers can do and what they actually use, and walks through the scenarios where the attacks happen. Main character energy for a threat model 💅

Status of This Memo ✨

This document is not an Internet Standards Track specification, so it's just being published for information 🧁

It's a product of the Internet Engineering Task Force (IETF), which means it reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🤓

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7375 🔗

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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 📜🫶

Table of Contents 🗂️

1. Introduction and Scope ..........................................2
2. Actors ..........................................................4
   2.1. Endpoints ..................................................4
   2.2. Intermediaries .............................................5
   2.3. Attackers ..................................................6
3. Attacks .........................................................6
   3.1. Voicemail Hacking via Impersonation ........................7
   3.2. Unsolicited Commercial Calling from Impersonated Numbers ...8
   3.3. Telephony Denial-of-Service Attacks ........................9
4. Attack Scenarios ...............................................10
   4.1. Solution-Specific Attacks .................................11
5. Security Considerations ........................................11
6. Informative References .........................................12
Acknowledgments ...................................................12
Author's Address ..................................................13

1. Introduction and Scope 🦋

Okay so the STIR problem statement [RFC7340] explains the whole vibe here (STIR stands for the Secure Telephone Identity Revisited working group, fyi 📞). The main thing powering robocalling, vishing, swatting, and related attacks is being able to impersonate a calling party number. 💀 The starkest examples are when automated callees on the Public Switched Telephone Network (PSTN) treat the calling number as a security check, like letting you into a voicemail system. 🙈

Robocallers use impersonation to hide who they are. On the ordinary PSTN they can block (withhold) their calling number from being shown, but callees are way less likely to pick up blocked calls, so looking like you're calling from some number, any number, is better for them. 📵

Robocallers also don't want to call from a number that can be traced back to them, so they impersonate numbers that aren't assigned to them. 🕵️‍♀️

The scope of impersonation in this threat model is only about showing a calling telephone number to the callee (a human or an automaton) when the call is set up. 🎯 The main attack vector is that the attacker makes the calling telephone number in the signaling be a number they picked. The number belongs to someone else, meaning the attacker isn't authorized to call from it, but they hand it over so it gets consumed or rendered on the terminating side. The threat model assumes this attack simply can't be prevented, since nothing can stop an attacker from building call setup messages that contain whatever calling numbers they want. So the solution space focuses on how terminating or intermediary elements can tell authorized calling party numbers from unauthorized ones, so that policies (human or automatic) can act on that info. Realistic? Maybe not. Focused? Absolutely 🔥

Securing an authenticated calling party number at call setup doesn't say anything about the entities that will send and receive media during the call itself. ✨ On call paths with intermediaries and gateways (more on that below), there may be no way to give any assurance in the signaling about who's in the media of a call. In end-to-end IP environments where that assurance is possible, it's highly desirable. 💖 But in this threat model, "impersonation" doesn't cover impersonating an authorized listener after the call is already established (like a third party trying to eavesdrop on a conversation). Attackers who could do that would need capabilities that robocallers and voicemail hackers are unlikely to have, and historically those attacks haven't been part of the robocalling or related problems. 🫣

In SIP, and even lots of traditional telephone protocols, call signaling can be renegotiated after the call is established. 🔄 Using the various transfer mechanisms common in telephone systems, a callee can easily be connected to, or conferenced in with, telephone numbers other than the original calling number once the call is up. These post-setup changes are outside the scope of impersonation in this model, because the motivating use cases (defeating robocalling, voicemail hacking, and swatting) all rely on impersonation during the initial call setup. 🎀 Also, this threat model doesn't include verifying the reached party's telephone number back to the originator of the call. The originator has no assurance that they're reaching the correct number, and no indication when call forwarding has happened. 🧐 This model only focuses on verifying the calling party number to the callee. 🫶

In much of the PSTN there's a supplemental service that translates calling party numbers into names, including the proper names of people and businesses, to show the called user. 🪪 These services (often marketed as part of 'Caller ID') are a further attack surface for impersonation. This threat model only addresses the calling party number, even though a forged calling party number can also cause a chosen calling party name to show up for the user. 😳 A verifiable calling party number does improve the security of calling party name systems, but this model doesn't consider attacks specific to names. Those attacks might target the databases the terminating side consults to get calling party names, or impersonators might forge a particular calling party number just to show a misleading name to the user. 🌸

2. Actors 🎭

2.1. Endpoints 📱

There are two main categories of end-user terminals relevant here: a dumb device (like a 'black phone') or a smart device. 🦋

  • Dumb devices have a simple dial pad, handset, and ringer, and optionally a display that can show a limited number of characters. Usually the display can fit a telephone number and an accompanying name, but sometimes it can show fewer. Users do interact with these devices, but the intelligence driving them lives in the service provider network. 🧠☁️
  • Smart devices are general-purpose computers with some degree of programmability and the ability to access the Internet and render text, audio, and/or images. This category includes smart phones, telephone applications on desktop and laptop computers, IP private branch exchanges, and so on. 💻📱

There's also a further category of automated terminals with no end user. These include systems like voicemail services, which may give a caller different services based solely on the calling party's number. For example, they might grant the (purported) mailbox owner access to a menu, while everyone else can only leave a message. 📨 Voicemail services vary wildly in capability, but many today have Internet access and advanced application interfaces, like rendering 'visual voicemail' [OMTP-VV] or automatically transcribing voicemail into email. 🌈

2.2. Intermediaries 🦋

Okay so the endpoints of a traditional phone call don't just talk directly. They bounce through a bunch of intermediary devices in the network 📞✨ The set of intermediary devices traversed during call setup between two endpoints is called a call path. The length of the call path can vary a LOT. In Voice over IP (VoIP) deployments, it's possible for two endpoints to send traffic straight to each other, but more commonly there are several intermediaries in a VoIP call path 💅 One or more gateways may also show up on a call path too.

  • Intermediaries forward call signaling to the next device in the path 🎀 They may also modify the signaling to improve interoperability, to enable proper network-layer media connections, or to enforce operator policy. This threat model assumes there are no restrictions on the modifications to signaling that an intermediary can introduce, which is consistent with the observed behavior of such devices 🙈
  • A gateway is a subtype of intermediary that translates call signaling from one protocol into another 🌈 In the process, they tend to consume any signaling specific to the original protocol (elements like transaction-matching identifiers), and they may need to transcode or otherwise alter identifiers as they get rendered in the destination protocol.

This threat model assumes that intermediaries and gateways can forward and retarget calls as necessary. That means a call can end up terminating somewhere the originator didn't expect, and this is a common condition in call routing 🧚 This matters for the solution space because it limits the ability of the originator to anticipate what the telephone number of the respondent will be. (For more on the "unanticipated respondent" problem, see [SIP-SECURITY].)

Furthermore, we assume that some intermediaries or gateways may, due to their capabilities or policies, discard calling party number information in whole or in part 👀 Today, many IP-PSTN gateways simply ignore any information available about the caller in the IP leg of the call, and they allow the telephone number of the Primary Rate Interface (PRI) line used by the gateway to be sent as the calling party number for the PSTN leg of the call. For example, a call might also gateway to a multi-frequency network where only a limited number of digits of automatic numbering identification (ANI) data are signaled. Some protocols may render telephone numbers in a way that makes it impossible for a terminating side to parse or canonicalize a number. In these cases, providing authenticated calling number data may be impossible, but this is not indicative of an attack or other security failure 🫶

2.3. Attackers 😈

We assume that an attacker has the following capabilities:

  • An attacker can create telephone calls at will, originating them either on the PSTN or over IP, and can supply an arbitrary calling party number 📱
  • An attacker can capture and replay signaling previously observed by it 🔁
  • An attacker has access to the Internet and thus the ability to inject arbitrary traffic over the Internet, to access public directories, etc. 🌐

There are attack scenarios in which an attacker compromises intermediaries in the call path or captures credentials that allow the attacker to impersonate a caller. Those system-level attacks are not considered in this threat model, though secure design and operation of systems to prevent these sorts of attacks are necessary for envisioned countermeasures to work 🔐 To date, robocallers and other impersonators do not resort to compromising systems. Instead, they exploit the intrinsic lack of secure identity in existing mechanisms, and remedying that problem lies within the scope of this threat model 💀

This threat model also does not consider scenarios in which the operators of intermediaries or gateways are themselves adversaries who intentionally discard valid identity information (without a user requesting anonymity) or who send falsified identity. See Section 4.1. 👑

3. Attacks 🔥

The uses of impersonation described in this section are broadly divided into two categories: those where an attack will not succeed unless the attacker impersonates a specific identity, and those where an attacker impersonates an arbitrary identity in order to disguise its own. At a high level, impersonation encourages targets to answer attackers' calls and makes identifying attackers more difficult 🙃 This section shows how concrete attacks based on those different techniques might be launched.

3.1. Voicemail Hacking via Impersonation 📼

A voicemail service may allow users calling from their phones access to their voicemail boxes on the basis of the calling party number. If an attacker wants to access the voicemail of a particular target, the attacker may try to impersonate the calling party number using one of the scenarios described in Section 4 🕵️‍♀️

This attack is closely related to attacks on similar automated systems, potentially including banks, airlines, calling-card services, conferencing providers, ISPs, and other businesses that fully or partly grant access to resources on the basis of the calling party number alone (rather than any shared secret or further identity check). It's analogous to an attack in which a human is encouraged to answer a phone or to divulge information once a call is in progress, by seeing a familiar calling party number 😬

The envisioned countermeasures for this attack involve the voicemail system treating calls that supply authenticated calling number data differently from other calls. In the absence of that identity information, for example, a voicemail service might enforce some other caller authentication policy (perhaps requiring a PIN for caller authentication). Asserted caller identity alone provides an authenticated basis for granting access to a voicemail box only when an identity is claimed legitimately. The absence of a verifiably legitimate calling identity here may not be evidence of malice, just of uncertainty or a limitation imposed by the set of intermediaries traversed for a specific call path 🥹

If the voicemail service could learn ahead of time that it should expect authenticated calling number data from a particular number, that would enable the voicemail service to adopt stricter policies for handling a request without authentication data. Since users typically contact a voicemail service repeatedly, the service could, for example, remember which requests contain authenticated calling number data and require further authentication mechanisms when identity is absent 🧠 The deployment of such a feature would be facilitated in many environments by the fact that the voicemail service is often operated by an organization that would be in a position to enable or require authentication of calling party identity (for example, carriers or enterprises). Even if the voicemail service is decoupled from the number assignee, issuers of credentials or other authorities could provide a service that informs verifiers that they should expect identity in calls from particular numbers ✨

3.2. Unsolicited Commercial Calling from Impersonated Numbers 📢

The unsolicited commercial calling, or 'robocalling' for short, attack is similar to the voicemail attack, except that the robocaller does not need to impersonate the particular number controlled by the target, merely some "plausible" number. A robocaller may impersonate a number that is not an assignable number (for example, in the United States, a number beginning with 0) or an unassigned number. This behavior is seen in the wild today 🤦‍♀️ A robocaller may change numbers every time a new call is placed, e.g., selecting numbers randomly.

A closely related attack is sending unsolicited bulk commercial messages via text messaging services. These messages usually originate on the Internet, though they may ultimately reach endpoints over traditional telephone network protocols or the Internet. While most text messaging endpoints are mobile phones, broadband residential services are increasingly supporting text messaging as well. The originators of these messages typically impersonate a calling party number, in some cases a "short code" specific to text messaging services 📱💌

The envisioned countermeasures to robocalling are similar to those in the voicemail example, but there are significant differences. One important potential countermeasure is simply to verify that the calling party number is in fact assignable and assigned. Unlike voicemail services, end users typically have never been contacted by the number used by a robocaller before, so they can't rely on past association to anticipate whether or not the calling party number should supply authenticated calling number data. If there were a service that could inform the terminating side that it should expect this data for calls or texts from that number, however, that would also help in the robocalling case 🙌

When a human callee is to be alerted at call setup time, the time frame for executing any countermeasures is necessarily limited. Ideally, a user would not be alerted that a call has been received until any necessary identity checks have been performed. This could, however, result in inordinate post-dial delay from the perspective of legitimate callers. Cryptographic and network operations must be minimized for these countermeasures to be practical ⏳ For text messages, a delay for executing anti-impersonation countermeasures is much less likely to degrade perceptible service.

The eventual effect of these countermeasures would be to force robocallers to either (a) block their caller identity, in which case end users could opt not to receive such calls or messages, or (b) use authenticated calling numbers traceable to them, which would then allow for other forms of redress 🚫📵

3.3. Telephony Denial-of-Service Attacks 📞💥

okay so TDoS attacks are kinda the drama queen of this whole topic 💅 The attacker uses impersonation to hide where the attack is coming from, and the goal is to tie up phone resources. They place so many calls that a target number becomes unreachable for legit callers 😩. The target could be a business, a regular person, or a public resource like emergency responders, and the attacker might be trying to extort them 💀. The attack calls can come from one endpoint or from a bunch of endpoints the attacker controls, and those endpoints can even sit in different administrative domains 🌍. Impersonation is what makes it so sneaky: it dodges any policy that blocks by originating number, and the victim can't figure out who the attacker is or even which service provider the attacker uses 🫥.

Like with robocalling, the attacker usually doesn't need to impersonate one specific number to launch a denial-of-service attack. The number just has to vary enough that simple policies can't block the attack calls 🎭. Still, an attacker might want everyone to think a particular party is to blame, and in that case they might impersonate a secondary target in the attack 👀.

The countermeasures they're picturing are twofold ✌️. First, same as with robocalling, making sure calling party numbers are assignable or assigned will help with the unsophisticated attacks 🙌. Second, if authenticated calling number data is supplied for legit calls, then Internet endpoints or intermediaries can make real policy decisions in the middle of an attack by deprioritizing unsigned calls when there's congestion ✨. Signed calls, if they're accepted, come with accountability in case they turn out to be malicious 🔏. This could even go as far as an originating network noticing congestion for a destination number and maybe dropping unsigned calls that are clearly part of a TDoS attack 🚫. And yes, just like robocalling, all of these countermeasures must execute in a timely manner to actually work ⏰.

Then there are certain flavors of TDoS attacks, including ones against emergency responders, where authenticated calling number data is probably not going to be a winning countermeasure 🚨. These entities are basically obligated to try to answer every call they get, and not having authenticated calling number data often won't remove that obligation 😭.

4. Attack Scenarios 🎬

The examples that follow rely on Internet protocols including SIP [RFC3261] and WebRTC [RTCWEB-OVERVIEW] 🧚.

Impersonation, IP-IP

An attacker with an IP phone sends a SIP request to an IP-enabled voicemail service 📱. The attacker puts a chosen calling party number into the From header field value of the INVITE. When the INVITE reaches the endpoint terminal, the terminal renders the attacker's chosen calling party number as the calling identity 🥲.

Impersonation, PSTN-PSTN

An attacker with a traditional Private Branch Exchange (PBX), connected to the PSTN through ISDN, sends a Q.931 SETUP request [Q931] with a chosen calling party number 📠. A service provider inserts that number into the corresponding SS7 [Q764] calling party number (CgPN) field of a call setup message, which is the Initial Address Message (IAM). When the call setup message reaches the endpoint switch, the terminal renders the attacker's chosen calling party number as the calling identity 🫣.

Impersonation, IP-PSTN

An attacker on the Internet uses a commercial WebRTC service to send a call to the PSTN with a chosen calling party number 🌐. The service contacts an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the SS7 [Q764] call setup message (the CgPN field of an IAM) 🚪. When the call setup message reaches the terminating telephone switch, the terminal renders the attacker's chosen calling party number as the calling identity 🎀.

Impersonation, IP-PSTN-IP

An attacker with an IP phone sends a SIP request to the telephone number of a voicemail service, perhaps without even knowing that the voicemail service is IP-based 🙈. The attacker puts a chosen calling party number into the From header field value of the INVITE. The attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the CgPN of an IAM 🔁. That IAM then traverses the PSTN until it reaches another gateway (perhaps after a call forwarding), this time back to the IP realm, to an H.323 network 🌀. The PSTN-IP gateway takes the calling party number in the IAM CgPN field and puts it into the SETUP request. When the SETUP reaches the endpoint terminal, the terminal renders the attacker's chosen calling party number as the calling identity 💫.

4.1. Solution-Specific Attacks

Solution-specific attacks are outside the scope of this document 🙅, though the STIR problem statement anticipates two sorts of solutions: in-band and out-of-band solutions (see [RFC7340]). There are a few points that future work on solution-specific threats must acknowledge 📝. The design of the credential system envisioned as a solution to these threats must, for example, limit the scope of the credentials issued to carriers or national authorities to those numbers that fall under their purview. This will impose limits on what (verifiable) assertions can be made by intermediaries 🧱.

Some of the attacks that should be considered in the future include the following 👀:

  • Attacks against in-band solutions
    • Replaying parts of messages used by the solution
    • Using a SIP REFER request to induce a party with access to credentials to place a call to a chosen number
    • Removing parts of messages used by the solution
  • Attacks against out-of-band solutions
    • Provisioning false or malformed data reflecting a placed call into any datastores that are part of the out-of-band mechanism
    • Mining any datastores that are part of the out-of-band mechanism
  • Attacks against either approach
    • Attack on any directories/services that report whether you should expect authenticated calling number data or not
    • Canonicalization attacks

5. Security Considerations 🔐

This document provides a threat model and is thus entirely about security. It's literally the whole point, so we are not joking around here 😤🔐.

6. Informative References 📚

Here's the reading list, copied exactly so nothing gets lost in translation 🫶.

[OMTP-VV]  Open Mobile Terminal Platform, "Visual Voice Mail
           Interface Specification", Version 1.3, June 2010,
           <http://www.gsma.com/newsroom/wp-content/uploads/2012/07/
           OMTP_VVM_Specification_1_3.pdf>.

[Q764]     ITU, "Signalling System No. 7 - ISDN User Part signalling
           procedures", Recommendation ITU-T Q.764, December 1999,
           <http://www.itu.int/rec/T-REC-Q.764/>.

[Q931]     ITU, "ISDN user-network interface layer 3 specification
           for basic call control", Recommendation ITU-T Q.931,
           May 1998, <http://www.itu.int/rec/T-REC-Q.931/>.

[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/rfc/rfc3261.txt>.

[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>.

[RTCWEB-OVERVIEW]
           Alvestrand, H., "Overview: Real Time Protocols for
           Browser-based Applications", Work in Progress,
           draft-ietf-rtcweb-overview-12, October 2014.

[SIP-SECURITY]
           Peterson, J., "Retargeting and Security in SIP: A
           Framework and Requirements", Work in Progress,
           draft-peterson-sipping-retarget-00, February 2005.

Acknowledgments 🫶

Huge thanks to Sanjay Mishra, David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen, Alex Bobotek, Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings, and Eric Rescorla, who provided key input to the discussions leading to this document 💜✨.

Author's Address 💌

Reach out to the author here 🦋:

Jon Peterson
NeuStar, Inc.
1800 Sutter St. Suite 570
Concord, CA  94520
United States

EMail: jon.peterson@neustar.biz
📦 where this page comes from