< draft-ietf-stir-problem-statement-00.txt   draft-ietf-stir-problem-statement-01.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Informational H. Schulzrinne Intended status: Informational H. Schulzrinne
Expires: April 07, 2014 Columbia University Expires: June 10, 2014 Columbia University
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
October 04, 2013 December 7, 2013
Secure Telephone Identity Problem Statement Secure Telephone Identity Problem Statement
draft-ietf-stir-problem-statement-00.txt draft-ietf-stir-problem-statement-01.txt
Abstract Abstract
Over the past decade, Voice over IP (VoIP) systems based on SIP have Over the past decade, Voice over IP (VoIP) systems based on SIP have
replaced many traditional telephony deployments. Interworking VoIP replaced many traditional telephony deployments. Interworking VoIP
systems with the traditional telephone network has reduced the systems with the traditional telephone network has reduced the
overall security of calling party number and Caller ID assurances by overall security of calling party number and Caller ID assurances by
granting attackers new and inexpensive tools to impersonate or granting attackers new and inexpensive tools to 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-
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 April 07, 2014. This Internet-Draft will expire on June 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 6 4.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 6
4.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 7 4.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 7
4.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 8 4.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 8
4.4. VoIP-to-PSTN Call Call . . . . . . . . . . . . . . . . . 8 4.4. VoIP-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 9
4.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 9 4.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 9
4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 10 4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 10
5. Limitations of Current Solutions . . . . . . . . . . . . . . 10 5. Limitations of Current Solutions . . . . . . . . . . . . . . 10
5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 11 5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 11
5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 12 5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 12
5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 17 6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 17
6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 17 6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 17
6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 18 6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 18
6.3. Public Key Infrastructure Developments . . . . . . . . . 18 6.3. Public Key Infrastructure Developments . . . . . . . . . 18
6.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 19 6.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 18
6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 19 6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 19
6.6. Relationship with Number Assignment and Management . . . 19 6.6. Relationship with Number Assignment and Management . . . 19
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Informative References . . . . . . . . . . . . . . . . . . . 21 11. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
skipping to change at page 3, line 17 skipping to change at page 3, line 17
identifying the communication parties in the end-to-end communication identifying the communication parties in the end-to-end communication
attempt derives from the need to implement authorization policies (to attempt derives from the need to implement authorization policies (to
grant or reject call attempts) but has also been utilized for grant or reject call attempts) but has also been utilized for
charging. While there are a number of ways to enable identification charging. While there are a number of ways to enable identification
this functionality has been provided by the Session Initiation this functionality has been provided by the Session Initiation
Protocol (SIP) [2] by using two main types of approaches, namely Protocol (SIP) [2] by using two main types of approaches, namely
using P-Asserted-Identity (PAI) [5] and SIP Identity [1], which are using P-Asserted-Identity (PAI) [5] and SIP Identity [1], which are
described in more detail in Section 5. The goal of these mechanisms described in more detail in Section 5. The goal of these mechanisms
is to validate that originator of a call is authorized to claim an is to validate that originator of a call is authorized to claim an
originating identifier. Protocols, like XMPP, use mechanisms that originating identifier. Protocols, like XMPP, use mechanisms that
are conceptional similar to those offered by SIP. are conceptually similar to those offered by SIP.
Although solutions have been standardized, it turns out that the Although solutions have been standardized, it turns out that the
current deployment situation is unsatisfactory and, even worse, there current deployment situation is unsatisfactory and, even worse, there
is little indication that it will be improved in the future. In [9] is little indication that it will be improved in the future. In [10]
we illustrate what challenges arise. In particular, interworking we illustrate what challenges arise. In particular, interworking
with different communication architectures (e.g., SIP, PSTN, XMPP, with different communication architectures (e.g., SIP, PSTN, XMPP,
RTCWeb) or other forms of mediation breaks the end-to-end semantic of RTCWeb) or other forms of mediation breaks the end-to-end semantic of
the communication interaction and destroys any identification the communication interaction and destroys any identification
capabilities. Furthermore, the use of different identifiers (e.g., capabilities. Furthermore, the use of different identifiers (e.g.,
E.164 numbers vs. SIP URIs) creates challenges for determining who is E.164 numbers vs. SIP URIs) creates challenges for determining who is
able to claim "ownership" for a specific identifier; although domain- able to claim "ownership" for a specific identifier; although domain-
based identifiers (sip:user@example.com) might use certificate or based identifiers (sip:user@example.com) might use certificate or
DNS-related approaches to determine who is able to claim "ownership" DNS-related approaches to determine who is able to claim "ownership"
of the URI, telephone numbers do not yet have any similar mechanism of the URI, telephone numbers do not yet have any similar mechanism
skipping to change at page 4, line 14 skipping to change at page 4, line 14
This model worked as long as the number of entities was relatively This model worked as long as the number of entities was relatively
small, easily identified (e.g., through the concept of certificated small, easily identified (e.g., through the concept of certificated
carriers) and subject to effective legal sanctions in case of carriers) and subject to effective legal sanctions in case of
misbehavior. However, for some time, these assumptions have no misbehavior. However, for some time, these assumptions have no
longer held true. For example, entities that are not traditional longer held true. For example, entities that are not traditional
telecommunication carriers, possibly located outside the country telecommunication carriers, possibly located outside the country
whose country code they are using, can act as voice service whose country code they are using, can act as voice service
providers. While in the past, there was a clear distinction between providers. While in the past, there was a clear distinction between
customers and service providers, VoIP service providers can now customers and service providers, VoIP service providers can now
easily act as customers, originating and transit providers. For easily act as customers, originating and transit providers. The
telephony, Caller ID spoofing has become common, with a small subset problem is moreover not limited to voice communications, as growth in
of entities either ignoring abuse of their services or willingly text messaging has made it another vector for bulk unsolicited
serving to enable fraud and other illegal behavior. commercial messaging relying on impersonation of a source telephone
number (sometimes a short code). For telephony, Caller ID spoofing
has become common, with a small subset of entities either ignoring
abuse of their services or willingly serving to enable fraud and
other illegal behavior.
For example, recently, enterprises and public safety organizations For example, recently, enterprises and public safety organizations
[15] have been subjected to telephony denial-of-service attacks. In [16] have been subjected to telephony denial-of-service attacks. In
this case, an individual claiming to represent a collections company this case, an individual claiming to represent a collections company
for payday loans starts the extortion scheme with a phone call to an for payday loans starts the extortion scheme with a phone call to an
organization. Failing to get payment from an individual or organization. Failing to get payment from an individual or
organization, the criminal organization launches a barrage of phone organization, the criminal organization launches a barrage of phone
calls, with spoofed numbers, preventing the targeted organization calls, with spoofed numbers, preventing the targeted organization
from receiving legitimate phone calls. Other boiler-room from receiving legitimate phone calls. Other boiler-room
organizations use number spoofing to place illegal "robocalls" organizations use number spoofing to place illegal "robocalls"
(automated telemarketing, see, for example, the FCC webpage [16] on (automated telemarketing, see, for example, the FCC webpage [17] on
this topic). Robocalls is a problem that has been recognized already this topic). Robocalls is a problem that has been recognized already
by various regulators, for example the Federal Communications by various regulators, for example the Federal Communications
Commission (FCC) recently organized a robocall competition to solicit Commission (FCC) recently organized a robocall competition to solicit
ideas for creating solutions that will block illegal robocalls [17]. ideas for creating solutions that will block illegal robocalls [18].
Criminals may also use number spoofing to impersonate banks or bank Criminals may also use number spoofing to impersonate banks or bank
customers to gain access to information or financial accounts. customers to gain access to information or financial accounts.
In general, number spoofing is used in two ways, impersonation and In general, number spoofing is used in two ways, impersonation and
anonymization. For impersonation, the attacker pretends to be a anonymization. For impersonation, the attacker pretends to be a
specific individual. Impersonation can be used for pretexting, where specific individual. Impersonation can be used for pretexting, where
the attacker obtains information about the individual impersonated, the attacker obtains information about the individual impersonated,
activates credit cards or for harassment, e.g., by causing utility activates credit cards or for harassment, e.g., by causing utility
services to be disconnected, take-out food to be delivered, or by services to be disconnected, take-out food to be delivered, or by
causing police to respond to a non-existing hostage situation causing police to respond to a non-existing hostage situation
("swatting", see [19]). Some voicemail systems can be set up so that ("swatting", see [20]). Some voicemail systems can be set up so that
they grant access to stored messages without a password, relying they grant access to stored messages without a password, relying
solely on the caller identity. As an example, the News International solely on the caller identity. As an example, the News International
phone-hacking scandal [18] has also gained a lot of press attention phone-hacking scandal [19] has also gained a lot of press attention
where employees of the newspaper were accused of engaging in phone where employees of the newspaper were accused of engaging in phone
hacking by utilizing Caller ID spoofing to get access to a voicemail. hacking by utilizing Caller ID spoofing to get access to a voicemail.
For numbers where the caller has suppressed textual caller For numbers where the caller has suppressed textual caller
identification, number spoofing can be used to retrieve this identification, number spoofing can be used to retrieve this
information, stored in the so-called Calling Name (CNAM) database. information, stored in the so-called Calling Name (CNAM) database.
For anonymization, the caller does not necessarily care whether the For anonymization, the caller does not necessarily care whether the
number is in service, or who it is assigned to, and may switch number is in service, or who it is assigned to, and may switch
rapidly and possibly randomly between numbers. Anonymization rapidly and possibly randomly between numbers. Anonymization
facilitates automated illegal telemarketing or telephony denial-of- facilitates automated illegal telemarketing or telephony denial-of-
service attacks, as described above, as it makes it difficult to service attacks, as described above, as it makes it difficult to
blacklist numbers. It also makes tracing such calls much more labor- blacklist numbers. It also makes tracing such calls much more labor-
intensive, as each such call has to be identified in each transit intensive, as each such call has to be identified in each transit
carrier hop-by-hop, based on destination number and time of call. carrier hop-by-hop, based on destination number and time of call.
Secure origin identification should prevent impersonation and, to a
lesser extent, anonymization. However, if numbers are easy and cheap
to obtain, and if the organizations assigning identifiers cannot or
will not establish the true corporate or individual identity of the
entity requesting such identifiers, robocallers will still be able to
switch between many different identities.
It is insufficient to simply outlaw all spoofing of originating It is insufficient to simply outlaw all spoofing of originating
telephone numbers, because the entities spoofing numbers are already telephone numbers, because the entities spoofing numbers are already
committing other crimes and thus unlikely to be deterred by legal committing other crimes and thus unlikely to be deterred by legal
sanctions. Also, in some cases, third parties may need to sanctions. Secure origin identification should prevent impersonation
and, to a lesser extent, anonymization. However, if numbers are easy
and cheap to obtain, and if the organizations assigning identifiers
cannot or will not establish the true corporate or individual
identity of the entity requesting such identifiers, robocallers will
still be able to switch between many different identities.
The problem space is further complicated by a number of use cases
where entities in the telephone network legitimately send calls on
behalf of others. Ultimately, any SIP entity can receive an INVITE
and forward it any other entity, and the recipient of a forwarded
message has little means to ascertain which recipient a call should
legitimately target. Also, in some cases, third parties may need to
temporarily use the identity of another individual or organization, temporarily use the identity of another individual or organization,
with full consent of the "owner" of the identifier. For example: with full consent of the "owner" of the identifier. For example:
The doctor's office: Physicians calling their patients using their The doctor's office: Physicians calling their patients using their
cell phones would like to replace their mobile phone number with cell phones would like to replace their mobile phone number with
the number of their office to avoid being called back by patients the number of their office to avoid being called back by patients
on their personal phone. on their personal phone.
Call centers: Call centers operate on behalf of companies and the Call centers: Call centers operate on behalf of companies and the
called party expects to see the Caller ID of the company, not the called party expects to see the Caller ID of the company, not the
call center. call center.
3. Terminology 3. Terminology
The following terms are defined in this document: The following terms are defined in this document:
In-band Identity Conveyance: In-band conveyance is the presence of In-band Identity Conveyance: In-band conveyance is the presence of
call origin identification information conveyed within SIP. It call origin identification information conveyed within the control
takes the nature of E.164 numbers and the prevalence of B2BUAs plane protocol(s) setting up a call. Any in-band solution must
into account. accommodate prevalence of in-band intermdiaries such as B2BUAs.
Out-of-Band Identity Verification: Out-of-band verification Out-of-Band Identity Verification: Out-of-band verification
determines whether the E.164 number used by the calling party determines whether the E.164 number used by the calling party
actually exists, whether the calling entity is entitled to use the actually exists, whether the calling entity is entitled to use the
number and whether a call has recently been made from this phone number and whether a call has recently been made from this phone
number. This approach is needed when the in-band technique does number. This approach is needed when the in-band technique does
not work due to intermediaries or due to interworking with PSTN not work due to intermediaries or due to interworking with PSTN
networks. networks.
Authority Delegation Infrastructure: This functionality defines how Authority Delegation Infrastructure: This functionality defines how
existing authority over E.164 telephoone numbers are used in existing authority over E.164 telephone numbers are used in number
number portability and delegation cases. It also describes how portability and delegation cases. It also describes how the
the existing numbering infrastructure is re-used to maintain the existing numbering infrastructure is re-used to maintain the
lifecycle of number assignments. lifecycle of number assignments.
Canonical Telephone Number: In order for either in-band conveyance Canonical Telephone Number: In order for either in-band conveyance
or out-of-band verification to work, entities in this architecture or out-of-band verification to work, entities in this architecture
must be able to canonicalize telephone numbers to arrive at a must be able to canonicalize telephone numbers to arrive at a
common syntactical form. common syntactical form.
4. Use Cases 4. Use Cases
In order to explain the requirements and other design assumptions we In order to explain the requirements and other design assumptions we
skipping to change at page 8, line 45 skipping to change at page 9, line 5
|VoIP | | |VoIP | |
|Interconnection| Invite +-------+ |Interconnection| Invite +-------+
|Provider(s) |----------->+ | |Provider(s) |----------->+ |
+---------------+ |Alice's| +---------------+ |Alice's|
|VSP | |VSP |
| | | |
+-------+ +-------+
Figure 3: PSTN-to-VoIP Call. Figure 3: PSTN-to-VoIP Call.
4.4. VoIP-to-PSTN Call Call 4.4. VoIP-to-PSTN Call
Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and
Alice an IP-based phone. When Alice initiates the call the E.164 Alice an IP-based phone. When Alice initiates the call the E.164
number needs to get translated to a SIP URI and subsequently to an IP number needs to get translated to a SIP URI and subsequently to an IP
address. The call of Alice traverses her VoIP provider where the address. The call of Alice traverses her VoIP provider where the
call origin identification information is added. It then hits the call origin identification information is added. It then hits the
PSTN/VoIP gateway. The gateway must verify that Alice can claim the PSTN/VoIP gateway. The gateway must verify that Alice can claim the
E.164 number she is using before it populates the corresponding E.164 number she is using before it populates the corresponding
calling party number field in telephone network signaling. Carl's calling party number field in telephone network signaling. Carl's
phone must be able to verify that it is receiving a legitimate call phone must be able to verify that it is receiving a legitimate call
skipping to change at page 9, line 36 skipping to change at page 9, line 45
|of Alice||a |of Alice||a
+--------+|i +--------+|i
-n -n
Figure 4: IP-to-PSTN Call. Figure 4: IP-to-PSTN Call.
4.5. PSTN-VoIP-PSTN Call 4.5. PSTN-VoIP-PSTN Call
Consider Figure 5 where Carl calls Alice. Both users have PSTN Consider Figure 5 where Carl calls Alice. Both users have PSTN
phones but interconnection between the two PSTN networks is phones but interconnection between the two PSTN networks is
accomplished via an IP network. Consequenly, Carl's operator uses a accomplished via an IP network. Consequently, Carl's operator uses a
PSTN-to-VoIP gateway to route the call via an IP network to a gateway PSTN-to-VoIP gateway to route the call via an IP network to a gateway
to break out into the PSTN again. to break out into the PSTN again.
+----------+ +----------+
|PSTN Phone| |PSTN Phone|
-------- |of Alice | -------- |of Alice |
//// \\\\ +----------+ //// \\\\ +----------+
+->| PSTN |------+ ^ +->| PSTN |------+ ^
| | | | | | | | | |
| \\\\ //// | | | \\\\ //// | |
| -------- | -------- | -------- | --------
| v //// \\\\ | v //// \\\\
| ,-------+ | PSTN | | ,-------+ | PSTN |
| |PSTN | | | | |PSTN | | |
+---+------+ __|VoIP GW|_ \\\\ //// +---+------+ __|VoIP GW|_ \\\\ ////
|PSTN Phone| / '`''''''' \ -------- |PSTN Phone| / '`''''''' \ --------
|of Carl | // | \\ ^ |of Carl | // | \\ ^
skipping to change at page 10, line 39 skipping to change at page 10, line 48
arbitrary user-supplied identity, much like the From header field arbitrary user-supplied identity, much like the From header field
value of an SMTP email message. During work on [2], efforts began to value of an SMTP email message. During work on [2], efforts began to
provide a secure origin for SIP requests as an extension to SIP. The provide a secure origin for SIP requests as an extension to SIP. The
so-called "short term" solution, the P-Asserted-Identity header so-called "short term" solution, the P-Asserted-Identity header
described in [5], is deployed fairly widely, even though it is described in [5], is deployed fairly widely, even though it is
limited to closed trusted networks where end-user devices cannot limited to closed trusted networks where end-user devices cannot
alter or inspect SIP messages and offers no cryptographic validation. alter or inspect SIP messages and offers no cryptographic validation.
As P-Asserted-Identity is used increasingly across multiple networks, As P-Asserted-Identity is used increasingly across multiple networks,
it cannot offer any protection against identity spoofing by it cannot offer any protection against identity spoofing by
intermediaries or entities that allow untrusted entities to set the P intermediaries or entities that allow untrusted entities to set the P
-Asserted-Identity information. -Asserted-Identity information. An overview of addressing spam in
SIP, and explaining how it differs from simiilar problems with email,
appeared in [9].
Subsequent efforts to prevent calling origin identity spoofing in SIP Subsequent efforts to prevent calling origin identity spoofing in SIP
include the SIP Identity effort (the "long term" identity solution) include the SIP Identity effort (the "long term" identity solution)
[1] and Verification Involving PSTN Reachability (VIPR) [13]. SIP [1] and Verification Involving PSTN Reachability (VIPR) [14]. SIP
Identity attaches a new header field to SIP requests containing a Identity attaches a new header field to SIP requests containing a
signature over the From header field value combined with other signature over the From header field value combined with other
message components to prevent replay attacks. SIP Identity is meant message components to prevent replay attacks. SIP Identity is meant
both to prevent originating calls with spoofed From headers and both to prevent originating calls with spoofed From headers and
intermediaries, such as SIP proxies, from launching man-in-the-middle intermediaries, such as SIP proxies, from launching man-in-the-middle
attacks to alter calls passing through. The VIPR architecture attacks to alter calls passing through. The VIPR architecture
attacked a broader range of problems relating to spam, routing and attacked a broader range of problems relating to spam, routing and
identity with a new infrastructure for managing rendezvous and identity with a new infrastructure for managing rendezvous and
security, which operated alongside of SIP deployments. security, which operated alongside of SIP deployments.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
provision to identify the assignee of a telephone number. While it provision to identify the assignee of a telephone number. While it
could be the case that the domain name portion of a SIP URI signifies could be the case that the domain name portion of a SIP URI signifies
a carrier (like "att.com") to whom numbers are assigned, the SIP a carrier (like "att.com") to whom numbers are assigned, the SIP
Identity mechanism provides no assurance that a number is assigned to Identity mechanism provides no assurance that a number is assigned to
any carrier. For a tel URI, moreover, it is unclear in [1] what any carrier. For a tel URI, moreover, it is unclear in [1] what
entity should hold a corresponding certificate. A caller may not entity should hold a corresponding certificate. A caller may not
want to reveal the identity of its service provider to the callee, want to reveal the identity of its service provider to the callee,
and may thus prefer tel URIs in the From header field. and may thus prefer tel URIs in the From header field.
This lack of authority gives rise to a whole class of SIP identity This lack of authority gives rise to a whole class of SIP identity
problems when dealing with telephone numbers, as is explored in [11]. problems when dealing with telephone numbers, as is explored in [12].
That document shows how the Identity header of a SIP request That document shows how the Identity header of a SIP request
targeting a telephone number (embedded in a SIP URI) could be dropped targeting a telephone number (embedded in a SIP URI) could be dropped
by an intermediate domain, which then modifies and resigns the by an intermediate domain, which then modifies and resigns the
request, all without alerting the verification service: the request, all without alerting the verification service: the
verification service has no way of knowing which original domain verification service has no way of knowing which original domain
signed the request. Provided that the local authentication service signed the request. Provided that the local authentication service
is complicit, an originator can claim virtually any telephone number, is complicit, an originator can claim virtually any telephone number,
impersonating any chosen Caller ID from the perspective of the impersonating any chosen Caller ID from the perspective of the
verifier. Both of these attacks are rooted in the inability of the verifier. Both of these attacks are rooted in the inability of the
verification service to ascertain a specific certificate that is verification service to ascertain a specific certificate that is
authoritative for a telephone number. authoritative for a telephone number.
As deployed, SIP is moreover highly mediated, and mediated in ways As deployed, SIP is moreover highly mediated, and mediated in ways
that [2] did not anticipate. As request routing commonly depends on that [2] did not anticipate. As request routing commonly depends on
policies dissimilar to [14], requests transit multiple intermediate policies dissimilar to [15], requests transit multiple intermediate
domains to reach a destination; some forms of intermediaries in those domains to reach a destination; some forms of intermediaries in those
domains may effectively re-initiate the session. domains may effectively re-initiate the session.
One of the main reasons that SIP deployments mimic the PSTN One of the main reasons that SIP deployments mimic the PSTN
architecture is because the requirement for interconnection with the architecture is because the requirement for interconnection with the
PSTN remains paramount: a call may originate in SIP and terminate on PSTN remains paramount: a call may originate in SIP and terminate on
the PSTN, or vice versa; and worse still, a PSTN-to-PSTN call may the PSTN, or vice versa; and worse still, a PSTN-to-PSTN call may
transit a SIP network in the middle, or vice versa. This necessarily transit a SIP network in the middle, or vice versa. This necessarily
reduces SIP's feature set to the least common dominator of the reduces SIP's feature set to the least common dominator of the
telephone network, and mandates support for telephone numbers as a telephone network, and mandates support for telephone numbers as a
skipping to change at page 16, line 41 skipping to change at page 16, line 41
moreover provide an authorization mechanism for accepting calls over moreover provide an authorization mechanism for accepting calls over
the Internet that significantly reduces the potential for spam. the Internet that significantly reduces the potential for spam.
Because the token can act as a nonce due to the presence of this out- Because the token can act as a nonce due to the presence of this out-
of-band connectivity, the VIPR token is less susceptible to cut-and- of-band connectivity, the VIPR token is less susceptible to cut-and-
paste attacks and thus needs to cover with its signature far less of paste attacks and thus needs to cover with its signature far less of
a SIP request. a SIP request.
Due to its narrow scope of applicability, and the details of its Due to its narrow scope of applicability, and the details of its
implementation, VIPR has some significant limitations. The most implementation, VIPR has some significant limitations. The most
salient for the purposes of this document is that it only has bearing salient for the purposes of this document is that it only has bearing
on repeated communications between entities: it has solution to the on repeated communications between entities: it has no solution to
classic "robocall" problem, where the target typically receives a the classic "robocall" problem, where the target typically receives a
call from a number that has never called before. All of VIPR's call from a number that has never called before. All of VIPR's
strengths in establishing identity and spam prevention kick in only strengths in establishing identity and spam prevention kick in only
after an initial PSTN call has been completed, and subsequent after an initial PSTN call has been completed, and subsequent
attempts at communication begin. Every VIPR-compliant entity attempts at communication begin. Every VIPR-compliant entity
moreover maintains its own stateful database of previous contacts and moreover maintains its own stateful database of previous contacts and
authorizations, which lends itself to more aggregators like IP PBXs authorizations, which lends itself to more aggregators like IP PBXs
that may front for thousands of users than to individual phones. that may front for thousands of users than to individual phones.
That database must be refreshed by periodic PSTN calls to determine That database must be refreshed by periodic PSTN calls to determine
that control over the number has not shifted to some other entity; that control over the number has not shifted to some other entity;
figuring out when data has grown stale is one the challenges of the figuring out when data has grown stale is one the challenges of the
skipping to change at page 17, line 49 skipping to change at page 17, line 49
In the years since [1] was conceived, there have been a number of In the years since [1] was conceived, there have been a number of
fundamental shifts in the communications marketplace. The most fundamental shifts in the communications marketplace. The most
transformative has been the precipitous rise of mobile smart phones, transformative has been the precipitous rise of mobile smart phones,
which are now arguably the dominant communications device in the which are now arguably the dominant communications device in the
developed world. Smart phones have both a PSTN and an IP interface, developed world. Smart phones have both a PSTN and an IP interface,
as well as an SMS and MMS capabilities. This suite of tools suggests as well as an SMS and MMS capabilities. This suite of tools suggests
that some of the techniques proposed by VIPR could be adapted to the that some of the techniques proposed by VIPR could be adapted to the
smart phone environment. The installed base of smart phones is smart phone environment. The installed base of smart phones is
moreover highly upgradable, and permits rapid adoption out-of-band moreover highly upgradable, and permits rapid adoption out-of-band
rendezvous services for smart phones that circumvent the PSTN: for rendezvous services for smart phones that circumvent the PSTN.
example, the Apple iMessage service, which allows iPhone users to Mobile messaging services that use telephone numbers as identities
send SMS messages to one another over the Internet rather than over allow smart phone users to send text messages to one another over the
the PSTN. Like VIPR, iMessage creates an out-of-band connection over Internet rather than over the PSTN. Like VIPR, such services create
the Internet between iPhones; unlike VIPR, the rendezvous service is an out-of-band connection over the Internet between smart phones;
provided by a trusted centralized database of iPhones rather than by unlike VIPR, the rendezvous service is provided by a trusted
a DHT. While Apple's service is specific to customers of its smart centralized database rather than by a DHT, and it is the centralized
phones, it seems clear that similar databases could be provided by database that effectively verifies and asserts the telephone number
neutral third parties in a position to coordinate between endpoints. of the sender of a message. While such messaging services are
specific to the users of the specific service, it seems clear that
similar databases could be provided by neutral third parties in a
position to coordinate between endpoints.
6.2. Failure of Public ENUM 6.2. Failure of Public ENUM
At the time [1] was written, the hopes for establishing a certificate At the time [1] was written, the hopes for establishing a certificate
authority for telephone numbers on the Internet largely rested on authority for telephone numbers on the Internet largely rested on
public ENUM deployment. The e164.arpa DNS tree established for ENUM public ENUM deployment. The e164.arpa DNS tree established for ENUM
could have grown to include certificates for telephone numbers or at could have grown to include certificates for telephone numbers or at
least for number ranges. It is now clear however that public ENUM as least for number ranges. It is now clear however that public ENUM as
originally envisioned has little prospect for adoption. That said, originally envisioned has little prospect for adoption. That said,
national authorities for telephone numbers are increasingly migrating some national authorities for telephone numbers are migrating their
their provisioning services to the Internet, and issuing credentials provisioning services to the Internet, and issuing credentials that
that express authority for telephone numbers to secure those express authority for telephone numbers to secure those services.
services. These new authorities for numbers could provide to the These new authorities for numbers could provide to the public
public Internet the necessary signatory authority for securing Internet the necessary signatory authority for securing calling
calling partys' numbers. While these systems are far from universal, partys' numbers. While these systems are far from universal, the
the authors of this draft believe that a solution devised for the authors of this draft believe that a solution devised for the North
North American Numbering Plan could have applicability to other American Numbering Plan could have applicability to other country
country codes. codes.
6.3. Public Key Infrastructure Developments 6.3. Public Key Infrastructure Developments
Also, there have been a number of recent high-profile compromises of Also, there have been a number of recent high-profile compromises of
web certificate authorities. The presence of numerous (in some web certificate authorities. The presence of numerous (in some
cases, of hundreds) of trusted certificate authorities in modern web cases, of hundreds) of trusted certificate authorities in modern web
browsers has become a significant security liability. As [1] relied browsers has become a significant security liability. As [1] relied
on web certificate authorities, this too provides new lessons for any on web certificate authorities, this too provides new lessons for any
work on revising [1]: namely, that innovations like DANE [6] that work on revising [1]: namely, that innovations like DANE [6] that
designate a specific certificate preferred by the owner of a DNS name designate a specific certificate preferred by the owner of a DNS name
skipping to change at page 19, line 6 skipping to change at page 19, line 4
could greatly improve the security of a SIP identity mechanism; and could greatly improve the security of a SIP identity mechanism; and
moreover, that when architecting new certificate authorities for moreover, that when architecting new certificate authorities for
telephone numbers, we should be wary of excessive pluralism. While a telephone numbers, we should be wary of excessive pluralism. While a
chain of delegation with a progressively narrowing scope of authority chain of delegation with a progressively narrowing scope of authority
(e.g., from a regulatory entity to a carrier to a reseller to an end (e.g., from a regulatory entity to a carrier to a reseller to an end
user) is needed to reflect operational practices, there is no need to user) is needed to reflect operational practices, there is no need to
have multiple roots, or peer entities that both claim authority for have multiple roots, or peer entities that both claim authority for
the same telephone number or number range. the same telephone number or number range.
6.4. Pervasive Nature of B2BUA Deployments 6.4. Pervasive Nature of B2BUA Deployments
Given the prevalence of established B2BUA deployments, we may have a Given the prevalence of established B2BUA deployments, we may have a
further opportunity to review the elements signed by [1] and to further opportunity to review the elements signed by [1] and to
decide on the value of alternative signature mechanisms. Separating decide on the value of alternative signature mechanisms. Separating
the elements necessary for (a) securing the From header field value the elements necessary for (a) securing the From header field value
and preventing replays, from (b) the elements necessary to prevent and preventing replays, from (b) the elements necessary to prevent
men-in-the-middle from tampering with messages, may also yield a men-in-the-middle from tampering with messages, may also yield a
strategy for identity that will be practicable in some highly strategy for identity that will be practicable in some highly
mediated networks. Solutions in this space must however remain mediated networks. Solutions in this space must however remain
mindful of the requirements for securing cryptographic material mindful of the requirements for securing cryptographic material
necessary to support DTLS-SRTP or future security mechanisms. necessary to support DTLS-SRTP or future security mechanisms.
6.5. Stickiness of Deployed Infrastructure 6.5. Stickiness of Deployed Infrastructure
One thing that has not changed, and is not likely to change in the One thing that has not changed, and is not likely to change in the
future, is the transitive nature of trust in the PSTN. When a call future, is the transitive nature of trust in the PSTN. When a call
from the PSTN arrives at a SIP gateway with a calling party number, from the PSTN arrives at a SIP gateway with a calling party number,
the gateway will have little chance of determining whether the the gateway will have little chance of determining whether the
originator of the call was authorized to claim that calling party originator of the call was authorized to claim that calling party
number. Due to roaming and countless other factors, calls on the number. Due to roaming and countless other factors, calls on the
PSTN may emerge from administrative domains that have no relationship PSTN may emerge from administrative domains that were not assigned
with the number assignee. This use case will remain the most the originating number. This use case will remain the most difficult
difficult to tackle for an identity system, and may prove beyond to tackle for an identity system, and may prove beyond repair. It
repair. It does however seem that with the changes in the solution does however seem that with the changes in the solution space, and a
space, and a better understanding of the limits of [1] and VIPR, we better understanding of the limits of [1] and VIPR, we are today in a
are today in a position to reexamine the problem space and find position to reexamine the problem space and find solutions that can
solutions that can have a significant impact on the secure origins have a significant impact on the secure origins problem.
problem.
6.6. Relationship with Number Assignment and Management 6.6. Relationship with Number Assignment and Management
Currently, telephone numbers are typically managed in a loose Currently, telephone numbers are typically managed in a loose
delegation hierarchy. For example, a national regulatory agency may delegation hierarchy. For example, a national regulatory agency may
task a private, neutral entity with administering numbering task a private, neutral entity with administering numbering
resources, such as area codes, and a similar entity with assigning resources, such as area codes, and a similar entity with assigning
number blocks to carriers and other authorized entities, who in turn number blocks to carriers and other authorized entities, who in turn
then assign numbers to customers. Resellers with looser regulatory then assign numbers to customers. Resellers with looser regulatory
obligations can complicate the picture, and in many cases it is obligations can complicate the picture, and in many cases it is
skipping to change at page 21, line 15 skipping to change at page 21, line 18
Display name: This effort does not consider how the display name of Display name: This effort does not consider how the display name of
the caller might be validated. the caller might be validated.
Response authentication: This effort only considers the problem of Response authentication: This effort only considers the problem of
providing secure telephone identity for requests, not for providing secure telephone identity for requests, not for
responses to requests; no solution is here proposed for the responses to requests; no solution is here proposed for the
problem of determining to which number a call has connected. problem of determining to which number a call has connected.
8. Acknowledgments 8. Acknowledgments
We would like to thank Alissa Cooper, Bernard Aboba, Sean Turner, We would like to thank Mike Hammer, Dan York, Andrew Allen, Philippe
Eric Burger, and Eric Rescorla for their discussion input that lead Fouquart, Hadriel Kaplan, Russ Housley, Alissa Cooper, Bernard Aboba,
to this document. Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for their
discussion input that lead to this document.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
This document is about improving the security of call origin This document is about improving the security of call origin
identification. identification.
skipping to change at page 22, line 15 skipping to change at page 22, line 17
[6] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [6] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[7] Elwell, J., "Connected Identity in the Session Initiation [7] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007. Protocol (SIP)", RFC 4916, June 2007.
[8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004. 3966, December 2004.
[9] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, [9] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[10] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba,
"Secure Call Origin Identification", draft-cooper-iab- "Secure Call Origin Identification", draft-cooper-iab-
secure-origin-00 (work in progress), November 2012. secure-origin-00 (work in progress), November 2012.
[10] Peterson, J., "Retargeting and Security in SIP: A [11] 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.
[11] Rosenberg, J., "Concerns around the Applicability of RFC [12] Rosenberg, J., "Concerns around the Applicability of RFC
4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in
progress), February 2008. progress), February 2008.
[12] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for [13] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for
Session Initiation Protocol (SIP) Back-to- Back User Session Initiation Protocol (SIP) Back-to- Back User
Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-02 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-02
(work in progress), September 2013. (work in progress), September 2013.
[13] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- [14] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability: Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings- Requirements and Architecture Overview", draft-jennings-
vipr-overview-04 (work in progress), February 2013. vipr-overview-04 (work in progress), February 2013.
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation [15] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002. 2002.
[15] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on [16] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on
Public Emergency Networks", URL: http:// Public Emergency Networks", URL: http://
krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion- krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-
attacks-on-public-emergency-networks/, Apr 2013. attacks-on-public-emergency-networks/, Apr 2013.
[16] FCC, ., "Robocalls", URL: [17] FCC, , "Robocalls", URL:
http://www.fcc.gov/guides/robocalls, Apr 2013. http://www.fcc.gov/guides/robocalls, Apr 2013.
[17] FCC, ., "FCC Robocall Challenge", URL: [18] FCC, , "FCC Robocall Challenge", URL:
http://robocall.challenge.gov/, Apr 2013. http://robocall.challenge.gov/, Apr 2013.
[18] Wikipedia, ., "News International phone hacking scandal", [19] Wikipedia, , "News International phone hacking scandal",
URL: http://en.wikipedia.org/wiki/ URL: http://en.wikipedia.org/wiki/
News_International_phone_hacking_scandal, Apr 2013. News_International_phone_hacking_scandal, Apr 2013.
[19] Wikipedia, ., "Don't Make the Call: The New Phenomenon of [20] Wikipedia, , "Don't Make the Call: The New Phenomenon of
'Swatting'", URL: http://www.fbi.gov/news/stories/2008/ 'Swatting'", URL: http://www.fbi.gov/news/stories/2008/
february/swatting020408, Feb 2008. february/swatting020408, Feb 2008.
Authors' Addresses Authors' Addresses
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
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
 End of changes. 44 change blocks. 
81 lines changed or deleted 99 lines changed or added

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