draft-ietf-stir-threats-02.txt   draft-ietf-stir-threats-03.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Informational February 10, 2014 Intended status: Informational June 11, 2014
Expires: August 14, 2014 Expires: December 13, 2014
Secure Telephone Identity Threat Model Secure Telephone Identity Threat Model
draft-ietf-stir-threats-02.txt draft-ietf-stir-threats-03.txt
Abstract Abstract
As the Internet and the telephone network have become increasingly As the Internet and the telephone network have become increasingly
interconnected and interdependent, attackers can impersonate or interconnected and interdependent, attackers can impersonate or
obscure calling party numbers when orchestrating bulk commercial obscure calling party numbers when orchestrating bulk commercial
calling schemes, hacking voicemail boxes or even circumventing multi- calling schemes, hacking voicemail boxes or even circumventing multi-
factor authentication systems trusted by banks. This document factor authentication systems trusted by banks. This document
analyzes threats in the resulting system, enumerating actors, analyzes threats in the resulting system, enumerating actors,
reviewing the capabilities available to and used by attackers, and reviewing the capabilities available to and used by attackers, and
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014. This Internet-Draft will expire on December 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 4. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Solution-Specific Attacks . . . . . . . . . . . . . . . . 10 4.1. Solution-Specific Attacks . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 11 8. Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction and Scope 1. Introduction and Scope
As is discussed in the STIR problem statement [2], the primary As is discussed in the STIR problem statement
enabler of robocalling, vishing, swatting and related attacks is the [I-D.ietf-stir-problem-statement], the primary enabler of
capability to impersonate a calling party number. The starkest robocalling, vishing, swatting and related attacks is the capability
examples of these attacks are cases where automated callees on the to impersonate a calling party number. The starkest examples of
PSTN rely on the calling number as a security measure, for example to these attacks are cases where automated callees on the PSTN rely on
access a voicemail system. Robocallers use impersonation as a means the calling number as a security measure, for example to access a
of obscuring identity; while robocallers can, in the ordinary PSTN, 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, block (that is, withhold) their calling number from presentation,
callees are less likely to pick up calls from blocked identities, and callees are less likely to pick up calls from blocked identities, and
therefore appearing to calling from some number, any number, is therefore appearing to calling from some number, any number, is
preferable. Robocallers however prefer not to call from a number preferable. Robocallers however prefer not to call from a number
that can trace back to the robocaller, and therefore they impersonate that can trace back to the robocaller, and therefore they impersonate
numbers that are not assigned to them. numbers that are not assigned to them.
The scope of impersonation in this threat model pertains solely to The scope of impersonation in this threat model pertains solely to
the rendering of a calling telephone number to a callee (human user 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 or automaton) at the time of call set-up. The primary attack vector
skipping to change at page 4, line 36 skipping to change at page 4, line 37
phones, telephone applications on desktop and laptop computers, IP phones, telephone applications on desktop and laptop computers, IP
private branch exchanges, etc. private branch exchanges, etc.
There is a further category of automated terminals without an end There is a further category of automated terminals without an end
user. These include systems like voicemail services, which may user. These include systems like voicemail services, which may
provide a different set of services to a caller based solely on the provide a different set of services to a caller based solely on the
calling party's number, for example granting the (purported) mailbox calling party's number, for example granting the (purported) mailbox
owner access to a menu while giving other callers only the ability to owner access to a menu while giving other callers only the ability to
leave a message. Though the capability of voicemail services varies leave a message. Though the capability of voicemail services varies
widely, many today have Internet access and advanced application widely, many today have Internet access and advanced application
interfaces (to render 'visual voicemail,' [7] to automatically interfaces (to render 'visual voicemail,' [refs.OMTP-VV] to
transcribe voicemail to email, etc.). automatically transcribe voicemail to email, etc.).
2.2. Intermediaries 2.2. Intermediaries
The endpoints of a traditional telephone call connect through The endpoints of a traditional telephone call connect through
numerous intermediary devices in the network. The set of numerous intermediary devices in the network. The set of
intermediary devices traversed during call setup between two intermediary devices traversed during call setup between two
endpoints is referred to as a call path. The length of the call path 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 can vary considerably: it is possible in VoIP deployments for two
endpoint entities to send traffic to one another directly, but, more endpoint entities to send traffic to one another directly, but, more
commonly, several intermediaries exist in a VoIP call path. One or commonly, several intermediaries exist in a VoIP call path. One or
skipping to change at page 5, line 19 skipping to change at page 5, line 22
A gateway is a subtype of intermediary that translates call A gateway is a subtype of intermediary that translates call
signaling from one protocol into another. In the process, they signaling from one protocol into another. In the process, they
tend to consume any signaling specific of the original protocol tend to consume any signaling specific of the original protocol
(elements like transaction-matching identifiers) and may need to (elements like transaction-matching identifiers) and may need to
transcode or otherwise alter identifiers as they are rendered in transcode or otherwise alter identifiers as they are rendered in
the destination protocol. the destination protocol.
This threat model assumes that intermediaries and gateways can This threat model assumes that intermediaries and gateways can
forward and retarget calls as necessary, which can result in a call forward and retarget calls as necessary, which can result in a call
terminating at a place the originator did not expect; this is an terminating at a place the originator did not expect; this is a
common condition in call routing. This observation is significant to common condition in call routing. This observation is significant to
the solution space, because it limits the ability of the originator the solution space, because it limits the ability of the originator
to anticipate what the telephone number of the respondent will be to anticipate what the telephone number of the respondent will be
(for more on the "unanticipated respondent" problem, see [4]). (for more on the "unanticipated respondent" problem, see
[I-D.peterson-sipping-retarget]).
Furthermore, we assume that some intermediaries or gateways may, due Furthermore, we assume that some intermediaries or gateways may, due
to their capabilities or policies, discard calling party number to their capabilities or policies, discard calling party number
information, in whole or part. Today, many IP-PSTN gateways simply information, in whole or in part. Today, many IP-PSTN gateways
ignore any information available about the caller in the IP leg of simply ignore any information available about the caller in the IP
the call, and allow the telephone number of the PRI line used by the leg of the call, and allow the telephone number of the PRI line used
gateway to be sent as the calling party number for the PSTN leg of by the gateway to be sent as the calling party number for the PSTN
the call. A call might also gateway to a multi-frequency network leg of the call. For example, a call might also gateway to a multi-
where only a limited number of digits of automatic numbering frequency network where only a limited number of digits of automatic
identification (ANI) data are signaled, for example. Some protocols numbering identification (ANI) data are signaled. Some protocols may
may render telephone numbers in a way that makes it impossible for a render telephone numbers in a way that makes it impossible for a
terminating side to parse or canonicalize a number. In these cases, terminating side to parse or canonicalize a number. In these cases,
providing authenticated calling number data may be impossible, but providing authenticated calling number data may be impossible, but
this is not indicative of an attack or other security failure. this is not indicative of an attack or other security failure.
2.3. Attackers 2.3. Attackers
We assume that an attacker has the following capabilities: We assume that an attacker has the following capabilities:
An attacker can create telephone calls at will, originating them An attacker can create telephone calls at will, originating them
either on the PSTN or over IP, and can supply an arbitrary calling either on the PSTN or over IP, and can supply an arbitrary calling
skipping to change at page 6, line 13 skipping to change at page 6, line 13
by it. by it.
An attacker has access to the Internet, and thus the ability to An attacker has access to the Internet, and thus the ability to
inject arbitrary traffic over the Internet, to access public inject arbitrary traffic over the Internet, to access public
directories, etc. directories, etc.
There are attack scenarios in which an attacker compromises There are attack scenarios in which an attacker compromises
intermediaries in the call path, or captures credentials that allow intermediaries in the call path, or captures credentials that allow
the attacker to impersonate a caller. Those system-level attacks are the attacker to impersonate a caller. Those system-level attacks are
not considered in this threat model, though secure design and not considered in this threat model, though secure design and
operation of systems to prevent these sorts of attacks is necessary operation of systems to prevent these sorts of attacks are necessary
for envisioned countermeasures to work. for envisioned countermeasures to work.
This threat model also does not consider scenarios in which the This threat model also does not consider scenarios in which the
operators of intermediaries or gateways are themselves adversaries operators of intermediaries or gateways are themselves adversaries
who intentionally discard valid identity information (without a user who intentionally discard valid identity information (without a user
requesting anonymity) or who send falsified identity; see requesting anonymity) or who send falsified identity; see
Section 4.1. Section 4.1.
3. Attacks 3. Attacks
skipping to change at page 7, line 19 skipping to change at page 7, line 19
limitation imposed by the set of intermediaries traversed for a limitation imposed by the set of intermediaries traversed for a
specific call path. specific call path.
If the voicemail service could learn ahead of time that it should If the voicemail service could learn ahead of time that it should
expect authenticated calling number data from a particular number, expect authenticated calling number data from a particular number,
that would enable the voicemail service to adopt stricter policies that would enable the voicemail service to adopt stricter policies
for handling a request without authentication data. Since users for handling a request without authentication data. Since users
typically contact a voicemail service repeatedly, the service could typically contact a voicemail service repeatedly, the service could
for example remember which requests contain authenticated calling for example remember which requests contain authenticated calling
number data and require further authentication mechanisms when number data and require further authentication mechanisms when
identity are absent. Alternatively, issuers of credentials or other identity is absent. Alternatively, issuers of credentials or other
authorities could provide a service that informs verifiers that they authorities could provide a service that informs verifiers that they
should expect identity in calls from particular numbers. should expect identity in calls from particular numbers.
3.2. Unsolicited Commercial Calling from Impersonated Numbers 3.2. Unsolicited Commercial Calling from Impersonated Numbers
The unsolicited commercial calling, or for short robocalling, attack The unsolicited commercial calling, or for short robocalling, attack
is similar to the voicemail attack, except that the robocaller does is similar to the voicemail attack, except that the robocaller does
not need to impersonate the particular number controlled by the not need to impersonate the particular number controlled by the
target, merely some "plausible" number. A robocaller may impersonate target, merely some "plausible" number. A robocaller may impersonate
a number that is not an assignable number (for example, in the United a number that is not an assignable number (for example, in the United
States, a number beginning with 0), or an unassigned number. A States, a number beginning with 0), or an unassigned number. A
robocaller may change numbers every time a new call is placed, e.g., robocaller may change numbers every time a new call is placed, e.g.,
selecting numbers randomly. selecting numbers randomly.
A closely related attack is sending unsolicited bulk commercial A closely related attack is sending unsolicited bulk commercial
messages via text messaging services. These messages usually messages via text messaging services. These messages usually
originate on the Internet, though they may ultimately reach endpoints originate on the Internet, though they may ultimately reach endpoints
over traditional telephone network protocols or the Internet. While over traditional telephone network protocols or the Internet. While
most text messaging endpoints are mobile phones, increasingly most text messaging endpoints are mobile phones, increasingly,
broadband residential services support text messaging as well. The broadband residential services support text messaging as well. The
originators of these messages typically impersonate a calling party originators of these messages typically impersonate a calling party
number, in some cases a "short code" specific to text messaging number, in some cases a "short code" specific to text messaging
services. services.
The envisioned countermeasures to robocalling are similar to those in The envisioned countermeasures to robocalling are similar to those in
the voicemail example, but there are significant differences. One the voicemail example, but there are significant differences. One
important potential countermeasure is simply to verify that the important potential countermeasure is simply to verify that the
calling party number is in fact assignable and assigned. Unlike calling party number is in fact assignable and assigned. Unlike
voicemail services, end users typically have never been contacted by voicemail services, end users typically have never been contacted by
skipping to change at page 9, line 24 skipping to change at page 9, line 24
There are certain flavors of TDoS attacks, including those against There are certain flavors of TDoS attacks, including those against
emergency responders, against which authenticated calling number data emergency responders, against which authenticated calling number data
is unlikely to be a successful countermeasure. These entities are is unlikely to be a successful countermeasure. These entities are
effectively obligated to attempt to respond to every call they effectively obligated to attempt to respond to every call they
receive, and the absence of authenticated calling number data in many receive, and the absence of authenticated calling number data in many
cases will not remove that obligation. cases will not remove that obligation.
4. Attack Scenarios 4. Attack Scenarios
The examples that follow rely on Internet protocols including SIP [1] The examples that follow rely on Internet protocols including SIP
and WebRTC [3]. [RFC3261] and WebRTC [I-D.ietf-rtcweb-overview].
Impersonation, IP-IP Impersonation, IP-IP
An attacker with an IP phone sends a SIP request to an IP-enabled An attacker with an IP phone sends a SIP request to an IP-enabled
voicemail service. The attacker puts a chosen calling party number voicemail service. The attacker puts a chosen calling party number
into the From header field value of the INVITE. When the INVITE into the From header field value of the INVITE. When the INVITE
reaches the endpoint terminal, the terminal renders the attacker's reaches the endpoint terminal, the terminal renders the attacker's
chosen calling party number as the calling identity. chosen calling party number as the calling identity.
Impersonation, PSTN-PSTN Impersonation, PSTN-PSTN
An attacker with a traditional PBX (connected to the PSTN through An attacker with a traditional PBX (connected to the PSTN through
ISDN) sends a Q.931 SETUP request with a chosen calling party number ISDN) sends a Q.931 SETUP request with a chosen calling party number
which a service provider inserts into the corresponding SS7 [5] which a service provider inserts into the corresponding SS7
calling party number (CgPN) field of a call setup message (IAM). [refs.Q764] calling party number (CgPN) field of a call setup message
When the call setup message reaches the endpoint switch, the terminal (IAM). When the call setup message reaches the endpoint switch, the
renders the attacker's chosen calling party number as the calling terminal renders the attacker's chosen calling party number as the
identity. calling identity.
Impersonation, IP-PSTN Impersonation, IP-PSTN
An attacker on the Internet uses a commercial WebRTC service to send 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 a call to the PSTN with a chosen calling party number. The service
contacts an Internet-to-PSTN gateway, which inserts the attacker's contacts an Internet-to-PSTN gateway, which inserts the attacker's
chosen calling party number into the SS7 [5] call setup message (the chosen calling party number into the SS7 [refs.Q764] call setup
CgPN field of an IAM). When the call setup message reaches the message (the CgPN field of an IAM). When the call setup message
terminating telephone switch, the terminal renders the attacker's reaches the terminating telephone switch, the terminal renders the
chosen calling party number as the calling identity. attacker's chosen calling party number as the calling identity.
Impersonation, IP-PSTN-IP Impersonation, IP-PSTN-IP
An attacker with an IP phone sends a SIP request to the telephone An attacker with an IP phone sends a SIP request to the telephone
number of a voicemail service, perhaps without even knowing that the number of a voicemail service, perhaps without even knowing that the
voicemail service is IP-based. The attacker puts a chosen calling voicemail service is IP-based. The attacker puts a chosen calling
party number into the From header field value of the INVITE. The party number into the From header field value of the INVITE. The
attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts
the attacker's chosen calling party number into the CgPN of an IAM. the attacker's chosen calling party number into the CgPN of an IAM.
That IAM then traverses the PSTN until (perhaps after a call That IAM then traverses the PSTN until (perhaps after a call
forwarding) it reaches another gateway, this time back to the IP forwarding) it reaches another gateway, this time back to the IP
realm, to an H.323 network. The PSTN-IP gateway puts takes the realm, to an H.323 network. The PSTN-IP gateway takes the calling
calling party number in the IAM CgPN field and puts it into the SETUP party number in the IAM CgPN field and puts it into the SETUP
request. When the SETUP reaches the endpoint terminal, the terminal request. When the SETUP reaches the endpoint terminal, the terminal
renders the attacker's chosen calling party number as the calling renders the attacker's chosen calling party number as the calling
identity. identity.
4.1. Solution-Specific Attacks 4.1. Solution-Specific Attacks
Solution-specific attacks are outside the scope of this document. Solution-specific attacks are outside the scope of this document.
There are a few points which future work on solution-specific threats There are a few points which future work on solution-specific threats
must acknowledge. The design of the credential system envisioned as must acknowledge. The design of the credential system envisioned as
a solution to this threats must for example limit the scope of the a solution to this threats must for example limit the scope of the
skipping to change at page 10, line 40 skipping to change at page 10, line 40
numbers that fall under their purview. This will impose limits on numbers that fall under their purview. This will impose limits on
what (verifiable) assertions can be made by intermediaries. what (verifiable) assertions can be made by intermediaries.
Some of the attacks that should be considered in the future include Some of the attacks that should be considered in the future include
the following: the following:
Attacks Against In-band Attacks Against In-band
Token replay Token replay
Baiting a call to a chosen number with a REFER
Removal of in-band signaling features Removal of in-band signaling features
Attacks Against Out-of-Band Attacks Against Out-of-Band
Provisioning Garbage CPRs Provisioning Garbage CPRs
Data Mining Data Mining
Attacks Against Either Approach Attacks Against Either Approach
Attack on directories/services that say whether you should expect Attack on directories/services that say whether you should expect
authenticated calling number data or not authenticated calling number data or not
Canonicalization attacks Canonicalization attacks
5. Acknowledgments 5. Acknowledgments
David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen, Alex Bobotek, Sanjay Mishra, David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen,
Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings and Eric Alex Bobotek, Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings
Rescorla provided key input to the discussions leading to this and Eric Rescorla provided key input to the discussions leading to
document. this document.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document provides a threat model and is thus entirely about This document provides a threat model and is thus entirely about
security. security.
8. Informative References 8. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [I-D.ietf-rtcweb-overview]
A., Peterson, J., Sparks, R., Handley, M., and E. Alvestrand, H., "Overview: Real Time Protocols for Brower-
Schooler, "SIP: Session Initiation Protocol", RFC 3261, based Applications", draft-ietf-rtcweb-overview-09 (work
June 2002. in progress), February 2014.
[2] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement", draft-ietf-stir-
problem-statement-03 (work in progress), January 2014.
[3] Alvestrand, H., "Overview: Real Time Protocols for Brower- [I-D.ietf-stir-problem-statement]
based Applications", draft-ietf-rtcweb-overview-08 (work Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
in progress), September 2013. Telephone Identity Problem Statement and Requirements",
draft-ietf-stir-problem-statement-05 (work in progress),
May 2014.
[4] Peterson, J., "Retargeting and Security in SIP: A [I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", draft-peterson-sipping- Framework and Requirements", draft-peterson-sipping-
retarget-00 (work in progress), February 2005. retarget-00 (work in progress), February 2005.
[5] ITU-T, , "Signaling System No. 7; ISDN User Part Signaling [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.
[refs.OMTP-VV]
OMTP, , "Visual Voice Mail Interface Specification", URL:
http://www.gsma.com/newsroom/wp-content/uploads/2012/07/
OMTP_VVM_Specification_1_3.pdf, May 1998.
[refs.Q764]
ITU-T, , "Signaling System No. 7; ISDN User Part Signaling
procedure", ITU-T URL: procedure", ITU-T URL:
http://www.itu.int/rec/T-REC-Q.764/_page.print, September http://www.itu.int/rec/T-REC-Q.764/_page.print, September
1997. 1997.
[6] ITU-T, , "ISDN user-network interface layer 3 [refs.Q931]
ITU-T, , "ISDN user-network interface layer 3
specification for basic call control", ITU-T URL: specification for basic call control", ITU-T URL:
http://www.itu.int/rec/T-REC-Q.931-199805-I/en, May 1998. http://www.itu.int/rec/T-REC-Q.931-199805-I/en, May 1998.
[7] OMTP, , "Visual Voice Mail Interface Specification", URL:
http://www.gsma.com/newsroom/wp-content/uploads/2012/07/
OMTP_VVM_Specification_1_3.pdf, May 1998.
Author's Address Author's Address
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
 End of changes. 25 change blocks. 
62 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/