One document matched: draft-ietf-stir-threats-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
-->
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.peterson-sipping-retarget SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.peterson-sipping-retarget.xml">
<!ENTITY I-D.ietf-rtcweb-overview SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-overview.xml">
<!ENTITY I-D.ietf-stir-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-stir-problem-statement.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-stir-threats-03.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="STIR Threats">Secure Telephone Identity Threat Model</title>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="NeuStar, Inc.">NeuStar, Inc.</organization>
<address>
<postal>
<street>1800 Sutter St Suite 570</street>
<city>Concord</city>
<region>CA</region>
<code>94520</code>
<country>US</country>
</postal>
<email>jon.peterson@neustar.biz</email>
</address>
</author>
<date year="2014" />
<!-- <area>
RAI
</area>-->
<keyword>SIP</keyword>
<keyword>Secure Origin Identification</keyword>
<keyword>Communication Security</keyword>
<keyword>RTCWeb</keyword>
<keyword>Threat</keyword>
<keyword>Real-Time Communication</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction and Scope">
<t>As is discussed in the STIR problem statement <xref target="I-D.ietf-stir-problem-statement"/>, 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 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, and therefore appearing to
calling from some number, any number, is preferable. Robocallers
however prefer not to call from a number that can trace back to the
robocaller, and therefore they impersonate numbers that are not
assigned to them.
</t>
<t> 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 set-up. 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.
</t>
<t> Securing an authenticated calling party number at call set-up
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.
</t>
<t> 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.
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 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.
</t>
<t> 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.
</t>
</section>
<section anchor="actors" title="Actors">
<section anchor="endpoints" title="Endpoints">
<t> 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.
<list>
<t> 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.
</t>
<t> 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.
</t></list></t>
<t> 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 widely, many today have
Internet access and advanced application interfaces (to render
'visual voicemail,' <xref target="refs.OMTP-VV"/> to automatically transcribe voicemail to email,
etc.).
</t>
</section>
<section anchor="intermed" title="Intermediaries">
<t> 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
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.
<list>
<t> 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).
</t>
<t> 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 of 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.
</t></list></t>
<t> 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 <xref target="I-D.peterson-sipping-retarget"/>).
</t>
<t> 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 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.
</t>
</section>
<section anchor="attackers" title="Attackers">
<t>We assume that an attacker has the following capabilities:<list style="bullets">
<t>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.
</t>
<t> An attacker can capture and replay signaling previously observed by it.
</t>
<t> An attacker has access to the Internet, and thus the ability to
inject arbitrary traffic over the Internet, to access public
directories, etc.
</t></list></t>
<t> 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.
</t>
<t> 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 <xref target="solution"/>.
</t>
</section>
</section>
<section anchor="attacks" title="Attacks">
<t>
The uses of impersonation described in this section are broadly divided into two categories: those where an attacker impersonates an arbitrary identity in order to disguise its own, and those where an attack will not succeed unless the attacker impersonates a specific identity. 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.
</t>
<section anchor="voicemail" title="Voicemail Hacking via Impersonation">
<t> 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 <xref target="scenarios"/>.
</t><t>
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. 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.
</t>
<t> The envisioned countermeasures for this attack involve the voicemail system
treating calls that supply
an 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 voice mailbox only when an identity is claimed legitimately;
the absence of 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.
</t>
<t> 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.
Alternatively, issuers of credentials or other authorities could provide a service
that informs verifiers that they should expect identity in calls from
particular numbers.
</t>
</section>
<section anchor="robocalling" title="Unsolicited Commercial Calling from Impersonated Numbers">
<t> The unsolicited commercial calling, or for short robocalling, 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. A robocaller may change numbers
every time a new call is placed, e.g., selecting numbers randomly.
</t>
<t>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, increasingly, broadband residential services support 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.
</t>
<t>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.
</t>
<t>
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.
</t>
<t> The eventual effect of these countermeasures would be to force
robocallers to either block their caller identity, in which case end
users could opt not to receive such calls or messages, or to force robocallers to use authenticated
calling numbers traceable to them, which would then allow for
other forms of redress.
</t>
</section>
<section anchor="tdos" title="Telephony Denial-of-Service Attacks">
<t>
In the case of telephony denial-of-service (or 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.
</t><t>
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, and in that case, the attacker might want to impersonate a secondary target in the attack.
</t><t>
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.
</t><t>
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.
</t>
</section>
</section>
<section anchor="scenarios" title="Attack Scenarios">
<t>
The examples that follow rely on Internet protocols including <xref target="RFC3261">SIP</xref> and <xref target="I-D.ietf-rtcweb-overview">WebRTC</xref>.
</t>
<t>Impersonation, IP-IP</t>
<t> 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.
</t>
<t>Impersonation, PSTN-PSTN</t>
<t> An attacker with a traditional PBX (connected to the PSTN through
ISDN) sends a Q.931 SETUP request with a chosen calling party
number which a service provider inserts into the corresponding SS7 <xref target="refs.Q764"/>
calling party number (CgPN) field of a
call setup 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.
</t>
<t>Impersonation, IP-PSTN</t>
<t> 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 <xref target="refs.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.
</t>
<t>Impersonation, IP-PSTN-IP</t>
<t> 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 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.
</t>
<section anchor="solution" title="Solution-Specific Attacks">
<t>Solution-specific attacks are outside the scope of this document. There are a few points which
future work on solution-specific threats must acknowledge. The design of the credential system
envisioned as a solution to this 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.</t>
<t> Some of the attacks that should be considered in the future include the following:</t>
<t>Attacks Against In-band<list>
<t>Token replay</t>
<t>Baiting a call to a chosen number with a REFER</t>
<t>Removal of in-band signaling features</t></list></t>
<t>Attacks Against Out-of-Band<list>
<t>Provisioning Garbage CPRs</t>
<t>Data Mining</t></list></t>
<t>Attacks Against Either Approach<list>
<t>Attack on directories/services that say whether you should expect authenticated calling number data or not</t>
<t>Canonicalization attacks</t></list></t>
</section>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document provides a threat model and is thus entirely about security.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
&RFC3261;
&I-D.ietf-stir-problem-statement;
&I-D.ietf-rtcweb-overview;
&I-D.peterson-sipping-retarget;
<reference anchor="refs.Q764">
<front>
<title>Signaling System No. 7; ISDN User Part Signaling procedure</title>
<author fullname="International Telecommunications Union" initials="" surname="ITU-T"></author>
<date month="September" year="1997" />
</front>
<seriesInfo name="ITU-T"
value="URL: http://www.itu.int/rec/T-REC-Q.764/_page.print" />
<format target="http://www.itu.int/"
type="HTML" />
</reference>
<reference anchor="refs.Q931">
<front>
<title>ISDN user-network interface layer 3 specification
for basic call control</title>
<author fullname="International Telecommunications Union" initials="" surname="ITU-T"></author>
<date month="May" year="1998" />
</front>
<seriesInfo name="ITU-T"
value="URL: http://www.itu.int/rec/T-REC-Q.931-199805-I/en" />
<format target="http://www.itu.int/rec/T-REC-Q.931-199805-I/en"
type="HTML" />
</reference>
<reference anchor="refs.OMTP-VV">
<front>
<title>Visual Voice Mail Interface Specification</title>
<author fullname="Open Mobile Terminal Platform" initials="" surname="OMTP"></author>
<date month="May" year="1998" />
</front>
<seriesInfo name=""
value="URL: http://www.gsma.com/newsroom/wp-content/uploads/2012/07/OMTP_VVM_Specification_1_3.pdf" />
<format target="http://www.gsma.com/newsroom/wp-content/uploads/2012/07/OMTP_VVM_Specification_1_3.pdf"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:30:17 |