diff options
Diffstat (limited to 'doc/rfc/rfc7375.txt')
| -rw-r--r-- | doc/rfc/rfc7375.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc7375.txt b/doc/rfc/rfc7375.txt new file mode 100644 index 0000000..b270bc2 --- /dev/null +++ b/doc/rfc/rfc7375.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Peterson +Request for Comments: 7375 NeuStar, Inc. +Category: Informational October 2014 +ISSN: 2070-1721 + + + Secure Telephone Identity Threat Model + +Abstract + + As the Internet and the telephone network have become increasingly + interconnected and interdependent, attackers can impersonate or + obscure calling party numbers when orchestrating bulk commercial + calling schemes, hacking voicemail boxes, or even circumventing + multi-factor authentication systems trusted by banks. This document + analyzes threats in the resulting system, enumerating actors, + reviewing the capabilities available to and used by attackers, and + describing scenarios in which attacks are launched. + +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/rfc7375. + + + + + + + + + + + + + + + + + +Peterson Informational [Page 1] + +RFC 7375 STIR Threats October 2014 + + +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 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 + + As is discussed in the STIR problem statement [RFC7340] (where "STIR" + refers to the Secure Telephone Identity Revisited working group), the + primary enabler of robocalling, vishing, swatting, and related + attacks is the capability to impersonate a calling party number. The + starkest examples of these attacks are cases where automated callees + on the Public Switched Telephone Network (PSTN) rely on the calling + number as a security measure, for example, to access a voicemail + system. Robocallers use impersonation as a means of obscuring + identity. While robocallers can, in the ordinary PSTN, block (that + is, withhold) their calling number from presentation, callees are + less likely to pick up calls from blocked identities; therefore, + appearing to call from some number, any number, is preferable. + + + + +Peterson Informational [Page 2] + +RFC 7375 STIR Threats October 2014 + + + However, robocallers prefer not to call from a number that can trace + back to the them, so they impersonate numbers that are not assigned + to them. + + The scope of impersonation in this threat model pertains solely to + the rendering of a calling telephone number to a callee (human user + or automaton) at the time of call setup. The primary attack vector + is therefore one where the attacker contrives for the calling + telephone number in signaling to be a chosen number. In this attack, + the number is one that the attacker is not authorized to use (as a + caller) but gives in order for that number to be consumed or rendered + on the terminating side. The threat model assumes that this attack + simply cannot be prevented: there is no way to stop the attacker from + creating call setup messages that contain attacker-chosen calling + telephone numbers. The solution space therefore focuses on ways that + terminating or intermediary elements might differentiate authorized + from unauthorized calling party numbers in order that policies, human + or automatic, might act on that information. + + Securing an authenticated calling party number at call setup time + does not entail any assertions about the entity or entities that will + send and receive media during the call itself. In call paths with + intermediaries and gateways (as described below), there may be no way + to provide any assurance in the signaling about participants in the + media of a call. In those end-to-end IP environments where such + assurance is possible, it is highly desirable. However, in the + threat model described in this document, "impersonation" does not + consider impersonating an authorized listener after a call has been + established (e.g., as a third party attempting to eavesdrop on a + conversation). Attackers that could impersonate an authorized + listener require capabilities that robocallers and voicemail hackers + are unlikely to possess, and historically, such attacks have not + played a role in enabling robocalling or related problems. + + In SIP, and even many traditional telephone protocols, call signaling + can be renegotiated after the call has been established. Using + 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 a call has been + established. These post-setup changes to the call are outside the + scope of impersonation considered in this model: the motivating use + cases of defeating robocalling, voicemail hacking, and swatting all + rely on impersonation during the initial call setup. Furthermore, + this threat model does not include in its scope the verification of + the reached party's telephone number back to the originator of the + call. There is no assurance to the originator that they are reaching + + + + + +Peterson Informational [Page 3] + +RFC 7375 STIR Threats October 2014 + + + the correct number, nor any indication when call forwarding has taken + place. This threat model is focused only on verifying the calling + party number to the callee. + + In much of the PSTN, there exists a supplemental service that + translates calling party numbers into names, including the proper + names of people and businesses, for rendering to the called user. + These services (frequently marketed as part of 'Caller ID') provide a + further attack surface for impersonation. The threat model described + in this document addresses only the calling party number, even though + presenting a forged calling party number may cause a chosen calling + party name to be rendered to the user as well. Providing a + verifiable calling party number therefore improves the security of + calling party name systems, but this threat model does not consider + attacks specific to names. Such attacks may be carried out against + the databases consulted by the terminating side of a call to provide + calling party names or by impersonators forging a particular calling + party number in order to present a misleading name to the user. + +2. Actors + +2.1. Endpoints + + There are two main categories of end-user terminals relevant to this + discussion, a dumb device (such as a 'black phone') or a smart + device: + + o Dumb devices comprise a simple dial pad, handset, and ringer, + optionally accompanied by a display that can render a limited + number of characters. Typically, the display renders enough + characters for a telephone number and an accompanying name, but + sometimes fewer are rendered. Although users interface with these + devices, the intelligence that drives them lives in the service + provider network. + + o Smart devices are general-purpose computers with some degree of + programmability and with the capacity to access the Internet and + to render text, audio, and/or images. This category includes + smart phones, telephone applications on desktop and laptop + computers, IP private branch exchanges, etc. + + There is a further category of automated terminals without an end + user. These include systems like voicemail services, which may + provide a different set of services to a caller based solely on the + calling party's number, for example, granting the (purported) mailbox + owner access to a menu while giving other callers only the ability to + leave a message. Though the capability of voicemail services varies + + + + +Peterson Informational [Page 4] + +RFC 7375 STIR Threats October 2014 + + + widely, many today have Internet access and advanced application + interfaces (to render 'visual voicemail' [OMTP-VV], to automatically + transcribe voicemail to email, etc.). + +2.2. Intermediaries + + The endpoints of a traditional telephone call connect through + numerous intermediary devices in the network. The set of + intermediary devices traversed during call setup between two + endpoints is referred to as a call path. The length of the call path + can vary considerably: it is possible in Voice over IP (VoIP) + deployments for two endpoint entities to send traffic to one another + directly, but, more commonly, several intermediaries exist in a VoIP + call path. One or more gateways also may appear on a call path. + + o Intermediaries forward call signaling to the next device in the + path. These intermediaries may also modify the signaling in order + 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). + + o 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 may need to + transcode or otherwise alter identifiers as they are rendered in + the destination protocol. + + This threat model assumes that intermediaries and gateways can + forward and retarget calls as necessary, which can result in a call + terminating at a place the originator did not expect; this is a + common condition in call routing. This observation is significant to + 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 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 + + + +Peterson Informational [Page 5] + +RFC 7375 STIR Threats October 2014 + + + 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: + + o 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. + + o An attacker can capture and replay signaling previously observed + by it. + + o 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 but rather + exploit the intrinsic lack of secure identity in existing mechanisms; + remedying this 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. + + + + + +Peterson Informational [Page 6] + +RFC 7375 STIR Threats October 2014 + + +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 is 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. + + + + + + +Peterson Informational [Page 7] + +RFC 7375 STIR Threats October 2014 + + +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. Thus, 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. + + + +Peterson Informational [Page 8] + +RFC 7375 STIR Threats October 2014 + + +3.3. Telephony Denial-of-Service Attacks + + In the case of telephony denial-of-service (TDoS) attacks, the attack + relies on impersonation in order to obscure the origin of an attack + that is intended to tie up telephone resources. By placing incessant + telephone calls, an attacker renders a target number unreachable by + legitimate callers. These attacks might target a business, an + individual, or a public resource like emergency responders; the + attacker may intend to extort the target. Attack calls may be placed + from a single endpoint or from multiple endpoints under the control + of the attacker, and the attacker may control endpoints in different + administrative domains. Impersonation, in this case, allows the + attack to evade policies that would block based on the originating + number and furthermore prevents the victim from learning the + perpetrator of the attack or even the originating service provider of + the attacker. + + As is the case with robocalling, the attacker typically does not have + to impersonate a specific number in order to launch a denial-of- + service attack. The number simply has to vary enough to prevent + simple policies from blocking the attack calls. An attacker may, + however, have a further intention to create the appearance that a + particular party is to blame for an attack; in that case, the + attacker might want to impersonate a secondary target in the attack. + + The envisioned countermeasures are twofold. First, as with + robocalling, ensuring that calling party numbers are assignable or + assigned will help mitigate unsophisticated attacks. Second, if + authenticated calling number data is supplied for legitimate calls, + then Internet endpoints or intermediaries can make effective policy + decisions in the middle of an attack by deprioritizing unsigned calls + when congestion conditions exist; signed calls, if accepted, have the + necessary accountability should it turn out they are malicious. This + could extend to include, for example, an originating network + observing a congestion condition for a destination number and perhaps + dropping unsigned calls that are clearly part of a TDoS attack. As + with robocalling, all of these countermeasures must execute in a + timely manner to be effective. + + There are certain flavors of TDoS attacks, including those against + emergency responders, against which authenticated calling number data + is unlikely to be a successful countermeasure. These entities are + effectively obligated to attempt to respond to every call they + receive, and the absence of authenticated calling number data in many + cases will not remove that obligation. + + + + + + +Peterson Informational [Page 9] + +RFC 7375 STIR Threats October 2014 + + +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, which a service + provider inserts into the corresponding SS7 [Q764] calling party + number (CgPN) field of a call setup message (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 + (perhaps after a call forwarding) it reaches another gateway, 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 + + + + +Peterson Informational [Page 10] + +RFC 7375 STIR Threats October 2014 + + + 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 two sorts of solutions are anticipated by the STIR problem + statement: 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: + + o 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 + + o 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 + + o 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. + + + + +Peterson Informational [Page 11] + +RFC 7375 STIR Threats October 2014 + + +6. Informative References + + [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 + + Sanjay Mishra, David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen, + Alex Bobotek, Henning Schulzrinne, Hannes Tschofenig, Cullen + Jennings, and Eric Rescorla provided key input to the discussions + leading to this document. + + + + + + + + + + +Peterson Informational [Page 12] + +RFC 7375 STIR Threats October 2014 + + +Author's Address + + Jon Peterson + NeuStar, Inc. + 1800 Sutter St. Suite 570 + Concord, CA 94520 + United States + + EMail: jon.peterson@neustar.biz + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson Informational [Page 13] + |