< draft-ietf-stir-problem-statement-03.txt   draft-ietf-stir-problem-statement-04.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: July 29, 2014 Columbia University Expires: November 10, 2014 Columbia University
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
January 25, 2014 May 9, 2014
Secure Telephone Identity Problem Statement Secure Telephone Identity Problem Statement and Requirements
draft-ietf-stir-problem-statement-03.txt draft-ietf-stir-problem-statement-04.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-
factor authentication systems trusted by banks. Despite previous factor authentication systems trusted by banks. Despite previous
attempts to provide a secure assurance of the origin of SIP attempts to provide a secure assurance of the origin of SIP
communications, we still lack of effective standards for identifying communications, we still lack of effective standards for identifying
the calling party in a VoIP session. This document examines the the calling party in a VoIP session. This document examines the
reasons why providing identity for telephone numbers on the Internet reasons why providing identity for telephone numbers on the Internet
has proven so difficult, and shows how changes in the last decade may has proven so difficult, and shows how changes in the last decade may
provide us with new strategies for attaching a secure identity to SIP provide us with new strategies for attaching a secure identity to SIP
sessions. sessions. It also gives high-level requirements for a solution in
this space.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 29, 2014. This Internet-Draft will expire on November 10, 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 40 skipping to change at page 2, line 40
4.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 10 4.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 10
4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 11 4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 11
5. Limitations of Current Solutions . . . . . . . . . . . . . . 11 5. Limitations of Current Solutions . . . . . . . . . . . . . . 11
5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 12 5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 12
5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 14 5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 14
5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 19 6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 19
6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 19 6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 19
6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 19 6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 19
6.3. Public Key Infrastructure Developments . . . . . . . . . 20 6.3. Public Key Infrastructure Developments . . . . . . . . . 20
6.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 20 6.4. Prevalence of B2BUA Deployments . . . . . . . . . . . . . 20
6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 20 6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 20
6.6. Relationship with Number Assignment and Management . . . 21 6.6. Concerns about Pervasive Monitoring . . . . . . . . . . . 21
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 21 6.7. Relationship with Number Assignment and Management . . . 21
7. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Informative References . . . . . . . . . . . . . . . . . . . 23 11. Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In many communication architectures that allow users to communicate In many communication architectures that allow users to communicate
with other users, the need for identifying the originating party that with other users, the need arises for identifying the originating
initiates a call or a messaging interaction arises. The desire for party that initiates a call or a messaging interaction. The desire
identifying the communication parties in the end-to-end communication for identifying communication parties in 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) [RFC3261] by using two main types of approaches,
using P-Asserted-Identity (PAI) [4] and SIP Identity [1], which are namely using P-Asserted-Identity (PAI) [RFC3325] and SIP Identity
described in more detail in Section 5. The goal of these mechanisms [RFC4474], which are described in more detail in Section 5. The goal
is to validate that originator of a call is authorized to claim an of these mechanisms is to validate that originator of a call is
originating identifier. Protocols, like XMPP, use mechanisms that authorized to claim an originating identifier. Protocols, like XMPP,
are conceptually similar to those offered by SIP. use mechanisms that 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 [10] is little indication that it will be improved in the future. In
we illustrate what challenges arise. In particular, interworking [I-D.cooper-iab-secure-origin] we illustrate what challenges arise.
with different communication architectures (e.g., SIP, PSTN, XMPP, In particular, interworking with different communication
RTCWeb) or other forms of mediation breaks the end-to-end semantic of architectures (e.g., SIP, PSTN, XMPP, RTCWeb) or other forms of
the communication interaction and destroys any identification mediation breaks the end-to-end semantic of the communication
capabilities. Furthermore, the use of different identifiers (e.g., interaction and destroys any identification capabilities.
E.164 numbers vs. SIP URIs) creates challenges for determining who is Furthermore, the use of different identifiers (e.g., E.164 numbers
able to claim "ownership" for a specific identifier; although domain- vs. SIP URIs) creates challenges for determining who is able to claim
based identifiers (sip:user@example.com) might use certificate or "ownership" for a specific identifier; although domain-based
DNS-related approaches to determine who is able to claim "ownership" identifiers (sip:user@example.com) might use certificate or DNS-
of the URI, telephone numbers do not yet have any similar mechanism related approaches to determine who is able to claim "ownership" of
the URI, telephone numbers do not yet have any similar mechanism
defined. defined.
After the publication of the PAI and SIP Identity specifications After the publication of the PAI and SIP Identity specifications
various further attempts have been made to tackle the topic but various further attempts have been made to tackle the topic but
unfortunately with little success. The complexity resides in the unfortunately with little success. The complexity resides in the
deployment situation and the long list of (often conflicting) deployment situation and the long list of (often conflicting)
requirements. A number of years have passed since the last attempts requirements. A number of years have passed since the last attempts
were made to improve the situation and we therefore believe it is were made to improve the situation and we therefore believe it is
time to give it another try. With this document we would like to time to give it another try. With this document we would like to
start an attempt to develop a common understanding of the problem start to develop a common understanding of the problem statement as
statement as well as requirements to develop a vision on how to well as basic requirements to develop a vision on how to advance the
advance the state of the art and to initiate technical work to enable state of the art and to initiate technical work to enable secure call
secure call origin identification. origin identification.
2. Problem Statement 2. Problem Statement
In the classical public-switched telephone network, a limited number In the classical public-switched telephone network, there were a
of carriers trusted each other, without any cryptographic validation, limited number of carriers, all of whom trusted each other to provide
to provide accurate caller origination information. In some cases, accurate caller origination information, in an evnironment without
national telecommunication regulation codified these obligations. any cryptographic validation. In some cases, national
This model worked as long as the number of entities was relatively telecommunication regulation codified these obligations. This model
small, easily identified (e.g., through the concept of certificated worked as long as the number of entities was relatively small, easily
carriers) and subject to effective legal sanctions in case of identified (e.g., in the manner carriers are certified int he US) and
misbehavior. However, for some time, these assumptions have no subject to effective legal sanctions in case of misbehavior.
longer held true. For example, entities that are not traditional However, for some time, these assumptions have no longer held true.
telecommunication carriers, possibly located outside the country For example, entities that are not traditional telecommunication
whose country code they are using, can act as voice service carriers, possibly located outside the country whose country code
providers. While in the past, there was a clear distinction between they are using, can act as voice service providers. While in the
customers and service providers, VoIP service providers can now past, there was a clear distinction between customers and service
easily act as customers, originating and transit providers. The providers, VoIP service providers can now easily act as customers,
problem is moreover not limited to voice communications, as growth in originating and transit providers. The problem is moreover not
text messaging has made it another vector for bulk unsolicited limited to voice communications, as growth in text messaging has made
commercial messaging relying on impersonation of a source telephone it another vector for bulk unsolicited commercial messaging relying
number (sometimes a short code). For telephony, Caller ID spoofing on impersonation of a source telephone number (sometimes a short
has become common, with a small subset of entities either ignoring code). For telephony, Caller ID spoofing has become common, with a
abuse of their services or willingly serving to enable fraud and small subset of entities either ignoring abuse of their services or
other illegal behavior. 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 [TDOS] have been subjected to telephony denial-of-service attacks.
this case, an individual claiming to represent a collections company In this case, an individual claiming to represent a collections
for payday loans starts the extortion scheme with a phone call to an company for payday loans starts the extortion scheme with a phone
organization. Failing to get payment from an individual or call to an organization. Failing to get payment from an individual
organization, the criminal organization launches a barrage of phone or organization, the criminal organization launches a barrage of
calls, with spoofed numbers, preventing the targeted organization phone calls, with spoofed numbers, preventing the targeted
from receiving legitimate phone calls. Other boiler-room organization from receiving legitimate phone calls. Other boiler-
organizations use number spoofing to place illegal "robocalls" room organizations use number spoofing to place illegal "robocalls"
(automated telemarketing, see, for example, the FCC webpage [16] on (automated telemarketing, see, for example, the US Federal
this topic). Robocalls are a problem that has been recognized Communications Commission webpage [robocall-fcc] on this topic).
already by various regulators; for example, the Federal Trade Robocalls are a problem that has been recognized already by various
Commission (FTC) recently organized a robocall competition to solicit regulators; for example, the US Federal Trade Commission (FTC)
ideas for creating solutions that will block illegal robocalls [17]. recently organized a robocall competition to solicit ideas for
Criminals may also use number spoofing to impersonate banks or bank creating solutions that will block illegal robocalls
customers to gain access to information or financial accounts. [robocall-competition]. Criminals may also use number spoofing to
impersonate banks or bank 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 [swatting]). Some voicemail systems can be set up
they grant access to stored messages without a password, relying so that they grant access to stored messages without a password,
solely on the caller identity. As an example, the News International relying solely on the caller identity. As an example, the News
phone-hacking scandal [18] has also gained a lot of press attention International phone-hacking scandal [news-hack] has also gained a lot
where employees of the newspaper were accused of engaging in phone of press attention where employees of the newspaper were accused of
hacking by utilizing Caller ID spoofing to get access to a voicemail. engaging in phone hacking by utilizing Caller ID spoofing to get
For numbers where the caller has suppressed textual caller access to a voicemail. For numbers where the caller has suppressed
identification, number spoofing can be used to retrieve this textual caller identification, number spoofing can be used to
information, stored in the so-called Calling Name (CNAM) database. retrieve this information, stored in the so-called Calling Name
For anonymization, the caller does not necessarily care whether the (CNAM) database. For anonymization, the caller does not necessarily
number is in service, or who it is assigned to, and may switch care whether the number is in service, or who it is assigned to, and
rapidly and possibly randomly between numbers. Anonymization may switch rapidly and possibly randomly between numbers.
facilitates automated illegal telemarketing or telephony denial-of- Anonymization facilitates automated illegal telemarketing or
service attacks, as described above, as it makes it difficult to telephony denial-of-service attacks, as described above, as it makes
identify perpetators and craft policies to block them. It also makes it difficult to identify perpetators and craft policies to block
tracing such calls much more labor-intensive, as each such call has them. It also makes tracing such calls much more labor-intensive, as
to be identified in each transit carrier hop-by-hop, based on each call has to be identified in each transit carrier hop-by-hop,
destination number and time of call. based on destination number and time of call.
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. Secure origin identification should prevent impersonation sanctions. Secure origin identification should prevent impersonation
and, to a lesser extent, anonymization. However, if numbers are easy and, to a lesser extent, anonymization. However, if numbers are easy
and cheap to obtain, and if the organizations assigning identifiers and cheap to obtain, and if the organizations assigning identifiers
cannot or will not establish the true corporate or individual cannot or will not establish the true corporate or individual
identity of the entity requesting such identifiers, robocallers will identity of the entity requesting such identifiers, robocallers will
still be able to switch between many different identities. still be able to switch between many different identities.
The problem space is further complicated by a number of use cases The problem space is further complicated by a number of use cases
where entities in the telephone network legitimately send calls on where entities in the telephone network legitimately send calls on
behalf of others, including "Find-Me/Follow-Me" services. behalf of others, including "Find-Me/Follow-Me" services.
Ultimately, any SIP entity can receive an INVITE and forward it any Ultimately, any SIP entity can receive an INVITE and forward it to
other entity, and the recipient of a forwarded message has little any other entity, and the recipient of a forwarded message has little
means to ascertain which recipient a call should legitimately target means to ascertain which recipient a call should legitimately target
(see [11]. Also, in some cases, third parties may need to (see [I-D.peterson-sipping-retarget]. Also, in some cases, third
temporarily use the identity of another individual or organization, parties may need to temporarily use the identity of another
with full consent of the "owner" of the identifier. For example: individual or organization, 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.
skipping to change at page 6, line 50 skipping to change at page 7, line 5
be altered. be altered.
4.1. VoIP-to-VoIP Call 4.1. VoIP-to-VoIP Call
For the IP-to-IP communication case, a group of service providers For the IP-to-IP communication case, a group of service providers
that offer interconnected VoIP service exchange calls using SIP end- that offer interconnected VoIP service exchange calls using SIP end-
to-end, but may also deliver some calls via circuit-switched to-end, but may also deliver some calls via circuit-switched
facilities, as described in separate use cases below. These service facilities, as described in separate use cases below. These service
providers use telephone numbers as source and destination providers use telephone numbers as source and destination
identifiers, either as the user component of a SIP URI (e.g., identifiers, either as the user component of a SIP URI (e.g.,
sip:12125551234@example.com) or as a tel URI [7]. sip:12125551234@example.com) or as a tel URI [RFC3966].
As illustrated in Figure 1, if Alice calls Bob, the call will use SIP As illustrated in Figure 1, if Alice calls Bob, the call will use SIP
end-to-end. (The call may or may not traverse the Internet.) end-to-end. (The call may or may not traverse the Internet.)
+------------+ +------------+
| IP-based | | IP-based |
| SIP Phone |<--+ | SIP Phone |<--+
| of Bob | | | of Bob | |
|+19175551234| | |+19175551234| |
+------------+ | +------------+ |
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Figure 2: IP-PSTN-IP Call. Figure 2: IP-PSTN-IP Call.
Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that
looks similar to this scenario since the original call content would, looks similar to this scenario since the original call content would,
in the worst case, be re-created on the call origination side. in the worst case, be re-created on the call origination side.
4.3. PSTN-to-VoIP Call 4.3. PSTN-to-VoIP Call
Consider Figure 3 where Carl is using a PSTN phone and initiates a Consider Figure 3 where Carl is using a PSTN phone and initiates a
call to Alice. Alice is using a VoIP-based phone. The call of Carl call to Alice. Alice is using a VoIP-based phone. The call from
traverses the PSTN and enters the Internet via a PSTN/VoIP gateway. Carl traverses the PSTN and enters the Internet via a PSTN/VoIP
This gateway attaches some identity information to the call, for gateway. This gateway attaches some identity information to the
example based on the information it had received through the PSTN, if call, for example, based on the caller identification information it
available. had received through the PSTN, if available.
-------- --------
//// \\\\ //// \\\\
+->| PSTN |--+ +->| PSTN |--+
| | | | | | | |
| \\\\ //// | | \\\\ //// |
| -------- | | -------- |
| | | |
| v | v
| +----+-------+ | +----+-------+
skipping to change at page 9, line 35 skipping to change at page 9, line 35
+---------------+ |Alice's| +---------------+ |Alice's|
|VSP | |VSP |
| | | |
+-------+ +-------+
Figure 3: PSTN-to-VoIP Call. Figure 3: PSTN-to-VoIP Call.
4.4. VoIP-to-PSTN 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 is 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. It is desirable that the gateway verify that PSTN/VoIP gateway. It is desirable that the gateway verify that
Alice can claim the E.164 number she is using before it populates the Alice can claim the E.164 number she is using before it populates the
corresponding calling party number field in telephone network corresponding calling party number field in telephone network
signaling. Carl's phone must be able to verify that it is receiving signaling. Carl's phone must be able to verify that it is receiving
a legitimate call from the calling party number it will render to a legitimate call from the calling party number it will render to
Carl. Carl.
+-------+ +-----+ -C +-------+ +-----+ -C
skipping to change at page 11, line 43 skipping to change at page 11, line 43
For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond
improvement, we may be able to use out-of-band IP connectivity at improvement, we may be able to use out-of-band IP connectivity at
both the originating and terminating carrier to validate the call both the originating and terminating carrier to validate the call
information. information.
5. Limitations of Current Solutions 5. Limitations of Current Solutions
From the inception of SIP, the From header field value has held an From the inception of SIP, the From header field value has held an
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 [RFC3261], efforts
provide a secure origin for SIP requests as an extension to SIP. The began to provide a secure origin for SIP requests as an extension to
so-called "short term" solution, the P-Asserted-Identity header SIP. The so-called "short term" solution, the P-Asserted-Identity
described in [4], is deployed fairly widely, even though it is header described in [RFC3325], is deployed fairly widely, even though
limited to closed trusted networks where end-user devices cannot it is limited to closed trusted networks where end-user devices
alter or inspect SIP messages and offers no cryptographic validation. cannot alter or inspect SIP messages and offers no cryptographic
As P-Asserted-Identity is used increasingly across multiple networks, validation. As P-Asserted-Identity is used increasingly across
it cannot offer any protection against identity spoofing by multiple networks, it cannot offer any protection against identity
intermediaries or entities that allow untrusted entities to set the P spoofing by intermediaries or entities that allow untrusted entities
-Asserted-Identity information. An overview of addressing spam in to set the P-Asserted-Identity information. An overview of
SIP, and explaining how it differs from simiilar problems with email, addressing spam in SIP, and explaining how it differs from simiilar
appeared in [8]. problems with email, appeared in [RFC5039].
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 [RFC4474] and Verification Involving PSTN Reachability (VIPR)
Identity attaches a new header field to SIP requests containing a [I-D.jennings-vipr-overview]. SIP Identity attaches a new header
signature over the From header field value combined with other field to SIP requests containing a signature over the From header
message components to prevent replay attacks. SIP Identity is meant field value combined with other message components to prevent replay
both to prevent originating calls with spoofed From headers and attacks. SIP Identity is meant to prevent both: (a) SIP UAs from
intermediaries, such as SIP proxies, from launching man-in-the-middle originating calls with spoofed From headers; and (b) intermediaries,
attacks to alter calls passing through. The VIPR architecture such as SIP proxies, from launching man-in-the-middle attacks by
attacked a broader range of problems relating to spam, routing and altering calls as they pass through the intermediaries. The VIPR
identity with a new infrastructure for managing rendezvous and architecture attacked a broader range of problems relating to spam,
security, which operated alongside of SIP deployments. routing and identity with a new infrastructure for managing
rendezvous and security, which operated alongside of SIP deployments.
As we will describe in more detail below, both SIP Identity and VIPR As we will describe in more detail below, both SIP Identity and VIPR
suffer from serious limitations that have prevented their deployment suffer from serious limitations that have prevented their deployment
at significant scale, but they may still offer ideas and protocol at significant scale, but they may still offer ideas and protocol
building blocks for a solution. building blocks for a solution.
5.1. P-Asserted-Identity 5.1. P-Asserted-Identity
The P-Asserted-Identity header field of SIP [4] provides a way for The P-Asserted-Identity header field of SIP [RFC3325] provides a way
trusted network entities to share with one another an authoritative for trusted network entities to share with one another an
identifier for the originator of a call. The value of P-Asserted- authoritative identifier for the originator of a call. The value of
Identity cannot be populated by a user, though if a user wants to P-Asserted-Identity cannot be populated by a user, though if a user
suggest an identity to the trusted network, a separate header (P wants to suggest an identity to the trusted network, a separate
-Preferred-Identity) enables them to do so. The features of the P header (P-Preferred-Identity) enables them to do so. The features of
-Asserted-Identity header evolved as part of a broader effort to the P-Asserted-Identity header evolved as part of a broader effort to
reach parity with traditional telephone network signaling mechanisms reach parity with traditional telephone network signaling mechanisms
for selectively sharing and restricting presentation of the calling for selectively sharing and restricting presentation of the calling
party number at the user level, while still allowing core network party number at the user level, while still allowing core network
elements to know the identity of the user for abuse prevention and elements to know the identity of the user for abuse prevention and
accounting. accounting.
In order for P-Asserted-Identity to have these properties, it In order for P-Asserted-Identity to have these properties, it
requires the existence of a trust domain as described in [3]. Any requires the existence of a trust domain as described in [RFC3324].
entity in the trust domain may add a P-Asserted-Identity header to a Any entity in the trust domain may add a P-Asserted-Identity header
SIP message, and any entity in the trust domain may forward a message to a SIP message, and any entity in the trust domain may forward a
with a P-Asserted-Identity header to any other entity in the trust message with a P-Asserted-Identity header to any other entity in the
domain. If a trusted entity forwards a SIP request to an untrusted trust domain. If a trusted entity forwards a SIP request to an
entity, however, the P-Asserted-Identity header must first be untrusted entity, however, the P-Asserted-Identity header must first
removed; most sorts of end user devices are outside trust domains. be removed; most sorts of end user devices are outside trust domains.
Sending a P-Asserted-Identity request to an untrusted entity could Sending a P-Asserted-Identity request to an untrusted entity could
leak potentially private information, such as the network-asserted leak potentially private information, such as the network-asserted
calling party number in a case where a caller has requested calling party number in a case where a caller has requested
presentation restriction. This concept of a trust domain is modeled presentation restriction. This concept of a trust domain is modeled
on the trusted network of devices that operate the traditional on the trusted network of devices that operate the traditional
telephone network. telephone network.
P-Asserted-Identity has been very successful in telephone replacement P-Asserted-Identity has been very successful in telephone replacement
deployments of SIP. It is an extremely simple in-band mechanism, deployments of SIP. It is an extremely simple in-band mechanism,
requiring no cryptographic operations. Since it is so reminiscent of requiring no cryptographic operations. Since it is so reminiscent of
skipping to change at page 13, line 30 skipping to change at page 13, line 31
more than by security standards, and thus the level of assurance of P more than by security standards, and thus the level of assurance of P
-Asserted-Identity is only as good as the least trustworthy member of -Asserted-Identity is only as good as the least trustworthy member of
a trust domain. Since the contents of P-Asserted-Identity are not a trust domain. Since the contents of P-Asserted-Identity are not
intended for consumption by end users, end users must trust that intended for consumption by end users, end users must trust that
their service provider participates in an appropriate trust domain, their service provider participates in an appropriate trust domain,
as there will be no direct evidence of the trust domain in SIP as there will be no direct evidence of the trust domain in SIP
signaling that end user devices receive. Since the mechanism is so signaling that end user devices receive. Since the mechanism is so
closely modeled on the traditional telephone network, it is unlikely closely modeled on the traditional telephone network, it is unlikely
to provide a higher level of security than that. to provide a higher level of security than that.
Since [4] was written, the whole notion of P- headers intended for Since [RFC3325] was written, the whole notion of P- headers intended
use in private SIP domains has also been deprecated (see [9], largely for use in private SIP domains has also been deprecated (see
because of overwhelming evidence that these headers were being used [RFC5727], largely because of overwhelming evidence that these
outside of private contexts and leaking into the public Internet. It headers were being used outside of private contexts and leaking into
is unclear how many deployments that make use of P-Asserted-Identity the public Internet. It is unclear how many deployments that make
in fact conform with the Spec-T requirements of RFC3324. use of P-Asserted-Identity in fact conform with the Spec-T
requirements of RFC3324.
P-Asserted-Identity also complicates the question of which URI should P-Asserted-Identity also complicates the question of which URI should
be presented to a user when a call is received. Per RFC3261, SIP be presented to a user when a call is received. Per RFC3261, SIP
user agents would render the contents of the From header field to a user agents would render the contents of the From header field to a
user when receiving an INVITE request, but what if the P-Asserted- user when receiving an INVITE request, but what if the P-Asserted-
Identity contains a more trustworthy URI, and presentation is not Identity contains a more trustworthy URI, and presentation is not
restricted? Subsequent proposals have suggested additional header restricted? Subsequent proposals have suggested additional header
fields to carry different forms of identity related to the caller, fields to carry different forms of identity related to the caller,
including billing identities. As the calling identities in a SIP including billing identities. As the calling identities in a SIP
request proliferate, the question of how to select one to render to request proliferate, the question of how to select one to render to
the end user becomes more difficult to answer. the end user becomes more difficult to answer.
5.2. SIP Identity 5.2. SIP Identity
The SIP Identity mechanism [1] provided two header fields for The SIP Identity mechanism [RFC4474] provided two header fields for
securing identity information in SIP requests: the Identity and securing identity information in SIP requests: the Identity and
Identity-Info header fields. Architecturally, the SIP Identity Identity-Info header fields. Architecturally, the SIP Identity
mechanism assumes a classic "SIP trapezoid" deployment in which an mechanism assumes a classic "SIP trapezoid" deployment in which an
authentication service, acting on behalf of the originator of a SIP authentication service, acting on behalf of the originator of a SIP
request, attaches identity information to the request which provides request, attaches identity information to the request which provides
partial integrity protection; a verification service acting on behalf partial integrity protection; a verification service acting on behalf
of the recipient validates the integrity of the request when it is of the recipient validates the integrity of the request when it is
received. received.
The Identity header field value contains a signature over a hash of The Identity header field value contains a signature over a hash of
skipping to change at page 14, line 44 skipping to change at page 14, line 44
means for the man-in-the-middle to direct session media to resource means for the man-in-the-middle to direct session media to resource
that the originator did not specify, and thus to impersonate an that the originator did not specify, and thus to impersonate an
intended listener. intended listener.
The Identity-Info header field value contains a URI designating the The Identity-Info header field value contains a URI designating the
location of the certificate corresponding to the private key that location of the certificate corresponding to the private key that
signed the hash in the Identity header. That certificate could be signed the hash in the Identity header. That certificate could be
passed by-value along with the SIP request, in which case a "cid" URI passed by-value along with the SIP request, in which case a "cid" URI
appears in Identity-Info, or by-reference, for example when the appears in Identity-Info, or by-reference, for example when the
Identity-Info header field value has the URL of a service that Identity-Info header field value has the URL of a service that
delivers the certificate. [1] imposes further constraints governing delivers the certificate. [RFC4474] imposes further constraints
the subject of that certificate: namely, that it must cover the governing the subject of that certificate: namely, that it must cover
domain name indicated in the domain component of the URI in the From the domain name indicated in the domain component of the URI in the
header field value of the request. From header field value of the request.
The SIP Identity mechanism, however, has two fundamental limitations The SIP Identity mechanism, however, has two fundamental limitations
that have precluded its deployment: first, that it provides Identity that have precluded its deployment: first, that it provides Identity
only for domain names rather than other identifiers; second, that it only for domain names rather than other identifiers; second, that it
does not tolerate intermediaries that alter the bodies, or certain does not tolerate intermediaries that alter the bodies, or certain
header fields, of SIP requests. header fields, of SIP requests.
As deployed, SIP predominantly mimics the structures of the telephone As deployed, SIP predominantly mimics the structures of the telephone
network, and thus uses telephone numbers as identifiers. Telephone network, and thus uses telephone numbers as identifiers. Telephone
numbers in the From header field value of a SIP request may appear as numbers in the From header field value of a SIP request may appear as
the user part of a SIP URI, or alternatively in an independent tel the user part of a SIP URI, or alternatively in an independent tel
URI. The certificate designated by the Identity-Info header field as URI. The certificate designated by the Identity-Info header field as
specified, however, corresponds only to the domain portion of a SIP specified, however, corresponds only to the domain portion of a SIP
URI in the From header field. As such, [1] does not have any URI in the From header field. As such, [RFC4474] does not have any
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 [RFC4474]
entity should hold a corresponding certificate. A caller may not what entity should hold a corresponding certificate. A caller may
want to reveal the identity of its service provider to the callee, not want to reveal the identity of its service provider to the
and may thus prefer tel URIs in the From header field. callee, 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 [12]. problems when dealing with telephone numbers, as is explored in
That document shows how the Identity header of a SIP request [I-D.rosenberg-sip-rfc4474-concerns]. That document shows how the
targeting a telephone number (embedded in a SIP URI) could be dropped Identity header of a SIP request targeting a telephone number
by an intermediate domain, which then modifies and resigns the (embedded in a SIP URI) could be dropped by an intermediate domain,
request, all without alerting the verification service: the which then modifies and re-signs the request, all without alerting
verification service has no way of knowing which original domain the verification service: the verification service has no way of
signed the request. Provided that the local authentication service knowing which original domain signed the request. Provided that the
is complicit, an originator can claim virtually any telephone number, local authentication service is complicit, an originator can claim
impersonating any chosen Caller ID from the perspective of the virtually any telephone number, impersonating any chosen Caller ID
verifier. Both of these attacks are rooted in the inability of the from the perspective of the verifier. Both of these attacks are
verification service to ascertain a specific certificate that is rooted in the inability of the verification service to ascertain a
authoritative for a telephone number. specific certificate that is 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 [RFC3261] did not anticipate. As request routing commonly
policies dissimilar to [14], requests transit multiple intermediate depends on policies dissimilar to [RFC3263], requests transit
domains to reach a destination; some forms of intermediaries in those multiple intermediate domains to reach a destination; some forms of
domains may effectively re-initiate the session. intermediaries in those 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
primary calling identifier. primary calling identifier.
skipping to change at page 16, line 38 skipping to change at page 16, line 38
SDP, including especially the IP addresses and ports associated with SDP, including especially the IP addresses and ports associated with
media. Consequently, a SIP request exiting a B2BUA has no necessary media. Consequently, a SIP request exiting a B2BUA has no necessary
relationship to the original request received by the B2BUA, much like relationship to the original request received by the B2BUA, much like
a request exiting a PSTN gateway has no necessary relationship to any a request exiting a PSTN gateway has no necessary relationship to any
SIP request in a pre-PSTN leg of the call. An Identity signature SIP request in a pre-PSTN leg of the call. An Identity signature
provided for the original INVITE has no bearing on the post-B2BUA provided for the original INVITE has no bearing on the post-B2BUA
INVITE, and, were the B2BUA to preserve the original Identity header, INVITE, and, were the B2BUA to preserve the original Identity header,
any verification service would detect a violation of the integrity any verification service would detect a violation of the integrity
protection. protection.
The SIP community has long been aware of these problems with [1] in The SIP community has long been aware of these problems with
practical deployments. Some have therefore proposed weakening the [RFC4474] in practical deployments. Some have therefore proposed
security constraints of [1] so that at least some deployments of weakening the security constraints of [RFC4474] so that at least some
B2BUAs will be compatible with integrity protection of SIP requests. deployments of B2BUAs will be compatible with integrity protection of
However, such solutions do not address one key problem identified SIP requests. However, such solutions do not address one key problem
above: the lack of any clear authority for telephone numbers, and the identified above: the lack of any clear authority for telephone
fact that some INVITE requests are generated by intermediaries rather numbers, and the fact that some INVITE requests are generated by
than endpoints. Removing the signature over the SDP from the intermediaries rather than endpoints. Removing the signature over
Identity header will not, for example, make it any clearer how a PSTN the SDP from the Identity header will not, for example, make it any
gateway should assert identity in an INVITE request. clearer how a PSTN gateway should assert identity in an INVITE
request.
5.3. VIPR 5.3. VIPR
Verification Involving PSTN Reachability (VIPR) directly attacks the Verification Involving PSTN Reachability (VIPR) directly attacks the
twin problems of identifying number assignees on the Internet and twin problems of identifying number assignees on the Internet and
coping with intermediaries that may modify signaling. To address the coping with intermediaries that may modify signaling. To address the
first problem, VIPR relies on the PSTN itself: it discovers which first problem, VIPR relies on the PSTN itself: it discovers which
endpoints on the Internet are reachable via a particular PSTN number endpoints on the Internet are reachable via a particular PSTN number
by calling the number on the PSTN to determine whom a call to that by calling the number on the PSTN to determine whom a call to that
number will reach. As VIPR-enabled Internet endpoints associated number will reach. As VIPR-enabled Internet endpoints associated
skipping to change at page 17, line 46 skipping to change at page 17, line 46
authenticate the source of future communications. authenticate the source of future communications.
Through this mechanism, the VIPR system provides a suite of Through this mechanism, the VIPR system provides a suite of
properties, ones that go well beyond merely securing the origins of properties, ones that go well beyond merely securing the origins of
communications. It also provides a routing system which dynamically communications. It also provides a routing system which dynamically
discovers mappings between telephone numbers and URIs, effectively discovers mappings between telephone numbers and URIs, effectively
building an ad hoc ENUM database in every VIPR implementation. The building an ad hoc ENUM database in every VIPR implementation. The
tokens exchanged over the out-of-band connection established by VIPR tokens exchanged over the out-of-band connection established by VIPR
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 cookie due to the presence of this
of-band connectivity, the VIPR token is less susceptible to cut-and- out-of-band connectivity, the VIPR token is less susceptible to cut-
paste attacks and thus needs to cover with its signature far less of and-paste attacks and thus needs to cover with its signature far less
a SIP request. of 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 no solution to on repeated communications between entities: it has no solution to
the 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
skipping to change at page 19, line 9 skipping to change at page 19, line 9
its need for an initial PSTN call to complete before any of VIPR's its need for an initial PSTN call to complete before any of VIPR's
benefits can be realized, and by the drawbacks of the highly-public benefits can be realized, and by the drawbacks of the highly-public
exchanges requires to create the out-of-band connection between VIPR exchanges requires to create the out-of-band connection between VIPR
entities. As such, there is no obvious solution to providing secure entities. As such, there is no obvious solution to providing secure
origin services for SIP on the Internet today. origin services for SIP on the Internet today.
6. Environmental Changes 6. Environmental Changes
6.1. Shift to Mobile Communication 6.1. Shift to Mobile Communication
In the years since [1] was conceived, there have been a number of In the years since [RFC4474] was conceived, there have been a number
fundamental shifts in the communications marketplace. The most of 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 of out-of-band
rendezvous services for smart phones that circumvent the PSTN. rendezvous services for smart phones that circumvent the PSTN.
Mobile messaging services that use telephone numbers as identities Mobile messaging services that use telephone numbers as identities
allow smart phone users to send text messages to one another over the allow smart phone users to send text messages to one another over the
Internet rather than over the PSTN. Like VIPR, such services create Internet rather than over the PSTN. Like VIPR, such services create
an out-of-band connection over the Internet between smart phones; an out-of-band connection over the Internet between smart phones;
unlike VIPR, the rendezvous service is provided by a trusted unlike VIPR, the rendezvous service is provided by a trusted
centralized database rather than by a DHT, and it is the centralized centralized database rather than by a DHT, and it is the centralized
database that effectively verifies and asserts the telephone number database that effectively verifies and asserts the telephone number
of the sender of a message. While such messaging services are of the sender of a message. While such messaging services are
specific to the users of the specific service, it seems clear that specific to the users of the specific service, it seems clear that
similar databases could be provided by neutral third parties in a similar databases could be provided by neutral third parties in a
position to coordinate between endpoints. 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 [RFC4474] was written, the hopes for establishing a
authority for telephone numbers on the Internet largely rested on certificate authority for telephone numbers on the Internet largely
public ENUM deployment. The e164.arpa DNS tree established for ENUM rested on public ENUM deployment. The e164.arpa DNS tree established
could have grown to include certificates for telephone numbers or at for ENUM could have grown to include certificates for telephone
least for number ranges. It is now clear however that public ENUM as numbers or at least for number ranges. It is now clear however that
originally envisioned has little prospect for adoption. That said, public ENUM as originally envisioned has little prospect for
some national authorities for telephone numbers are migrating their adoption. That said, some national authorities for telephone numbers
provisioning services to the Internet, and issuing credentials that are migrating their provisioning services to the Internet, and
express authority for telephone numbers to secure those services. issuing credentials that express authority for telephone numbers to
These new authorities for numbers could provide to the public secure those services. These new authorities for numbers could
Internet the necessary signatory authority for securing calling provide to the public Internet the necessary signatory authority for
partys' numbers. While these systems are far from universal, the securing calling partys' numbers. While these systems are far from
authors of this draft believe that a solution devised for the North universal, the authors of this draft believe that a solution devised
American Numbering Plan could have applicability to other country for the North American Numbering Plan could have applicability to
codes. other country 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 [RFC4474]
on web certificate authorities, this too provides new lessons for any relied on web certificate authorities, this too provides new lessons
work on revising [1]: namely, that innovations like DANE [5] that for any work on revising [RFC4474]: namely, that innovations like
designate a specific certificate preferred by the owner of a DNS name DANE [RFC6698] that designate a specific certificate preferred by the
could greatly improve the security of a SIP identity mechanism; and owner of a DNS name could greatly improve the security of a SIP
moreover, that when architecting new certificate authorities for identity mechanism; and moreover, that when considering new
telephone numbers, we should be wary of excessive pluralism. While a certificate authorities for telephone numbers, we should be wary of
chain of delegation with a progressively narrowing scope of authority excessive pluralism. While a chain of delegation with a
(e.g., from a regulatory entity to a carrier to a reseller to an end progressively narrowing scope of authority (e.g., from a regulatory
user) is needed to reflect operational practices, there is no need to entity to a carrier to a reseller to an end user) is needed to
have multiple roots, or peer entities that both claim authority for reflect operational practices, there is no need to have multiple
the same telephone number or number range. roots, or peer entities that both claim authority for the same
telephone number or number range.
6.4. Pervasive Nature of B2BUA Deployments 6.4. Prevalence 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 [RFC4474] 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
skipping to change at page 20, line 48 skipping to change at page 20, line 49
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 were not assigned PSTN may emerge from administrative domains that were not assigned
the originating number. This use case will remain the most difficult the originating number. This use case will remain the most difficult
to tackle for an identity system, and may prove beyond repair. It to tackle for an identity system, and may prove beyond repair. It
does however seem that with the changes in the solution space, and a does however seem that with the changes in the solution space, and a
better understanding of the limits of [1] and VIPR, we are today in a better understanding of the limits of [RFC4474] and VIPR, we are
position to reexamine the problem space and find solutions that can today in a position to reexamine the problem space and find solutions
have a significant impact on the secure origins problem. that can have a significant impact on the secure origins problem.
6.6. Relationship with Number Assignment and Management 6.6. Concerns about Pervasive Monitoring
While spoofing the origins of communication is a source of numerous
security concerns, solutions for identifying communications must also
be mindful of the security risks of pervasive monitoring (see
[I-D.farrell-perpass-attack]). Identifying information, once it is
attached to communications, can potentially be inspected by parties
other than the intended recipient and collected for any number of
reasons. As stated above, the purpose of this work is not to
eliminate anonymity, but furthermore, to be viable and in the public
interest, solutions should not facilitate the unauthorized collection
of calling data.
6.7. 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
difficult to distinguish the roles of enterprises from carriers. In difficult to distinguish the roles of enterprises from carriers. In
many countries, individual numbers are portable between carriers, at many countries, individual numbers are portable between carriers, at
skipping to change at page 21, line 35 skipping to change at page 21, line 48
the assignment of numbers does not depend on providing actual call the assignment of numbers does not depend on providing actual call
delivery services. delivery services.
Databases today already map telephone numbers to entities that have Databases today already map telephone numbers to entities that have
been assigned the number, e.g., through the LERG (originally, Local been assigned the number, e.g., through the LERG (originally, Local
Exchange Routing Guide) in the United States. Thus, the transition Exchange Routing Guide) in the United States. Thus, the transition
to IP-based networks may offer an opportunity to integrate to IP-based networks may offer an opportunity to integrate
cryptographic bindings between numbers or number ranges and service cryptographic bindings between numbers or number ranges and service
providers into databases. providers into databases.
7. Requirements 7. Basic Requirements
This section describes the high level requirements of the effort: This section describes only the high level requirements of the
effort, which we expected will be further articulated as work
continues:
Generation: Intermediaries as well as end system must be able to Generation: Intermediaries as well as end system must be able to
generate the source identity information. generate the source identity information.
Validation: Intermediaries as well as end system must be able to Validation: Intermediaries as well as end system must be able to
validate the source identity information. validate the source identity information.
Usability: Any validation mechanism must work without human Usability: Any validation mechanism must work without human
intervention, e.g., CAPTCHA-like mechanisms. intervention, that is, without for exammple CAPTCHA-like
mechanisms.
Deployability: Must survive transition of the call to the PSTN and Deployability: Must survive transition of the call to the PSTN and
the presence of B2BUAs. the presence of B2BUAs.
Reflecting existing authority: Must stage credentials on existing Reflecting existing authority: Must stage credentials on existing
national-level number delegations, without assuming the need for national-level number delegations, without assuming the need for
an international golden root on the Internet. an international golden root on the Internet.
Accommodating current practices: Must allow number portability among Accommodating current practices: Must allow number portability among
carriers and must support legitimate usage of number spoofing carriers and must support legitimate usage of number spoofing
(doctor's office and call centers) (doctor's office and call centers)
Minimal payload overhead: Must lead to minimal expansion of SIP Minimal payload overhead: Must lead to minimal expansion of SIP
headers fields to avoid fragmentation in deployments that use UDP. headers fields to avoid fragmentation in deployments that use UDP.
Efficiency: Must minimize RTTs for any network lookups and minimize Efficiency: Must minimize RTTs for any network lookups and minimize
any necessary cryptographic operations. any necessary cryptographic operations.
Privacy: Any out-of-band validation protocol must not allows third Privacy: A solution must prevent unauthorized third parties from
parties to learn what numbers have been called by a specific learning what numbers have been called by a specific caller.
caller.
Some requirements specifically outside the scope of the effort Some requirements specifically outside the scope of the effort
include: include:
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 Fernando Mousinho, David Frankel, Penn Pfautz, We would like to thank Sanjay Mishra, Fernando Mousinho, David
Mike Hammer, Dan York, Andrew Allen, Philippe Fouquart, Hadriel Frankel, Penn Pfautz, Mike Hammer, Dan York, Andrew Allen, Philippe
Kaplan, Richard Shockey, Russ Housley, Alissa Cooper, Bernard Aboba, Fouquart, Hadriel Kaplan, Richard Shockey, Russ Housley, Alissa
Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for their Cooper, Bernard Aboba, Sean Turner, Brian Rosen, Eric Burger, and
discussion input that lead to this document. 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; security considerations for specific solutions will
be discussed in solutions documents.
11. Informative References 11. Informative References
[1] Peterson, J. and C. Jennings, "Enhancements for [I-D.cooper-iab-secure-origin]
Authenticated Identity Management in the Session Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba,
Initiation Protocol (SIP)", RFC 4474, August 2006. "Secure Call Origin Identification", draft-cooper-iab-
secure-origin-00 (work in progress), November 2012.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [I-D.farrell-perpass-attack]
Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an
Attack", draft-farrell-perpass-attack-06 (work in
progress), February 2014.
[I-D.jennings-vipr-overview]
Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013.
[I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", draft-peterson-sipping-
retarget-00 (work in progress), February 2005.
[I-D.rosenberg-sip-rfc4474-concerns]
Rosenberg, J., "Concerns around the Applicability of RFC
4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in
progress), February 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[3] Watson, M., "Short Term Requirements for Network Asserted [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002. Identity", RFC 3324, November 2002.
[4] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[5] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
of Named Entities (DANE) Transport Layer Security (TLS) 3966, December 2004.
Protocol: TLSA", RFC 6698, August 2012.
[6] Elwell, J., "Connected Identity in the Session Initiation [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Protocol (SIP)", RFC 4916, June 2007. Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
3966, December 2004. Protocol (SIP)", RFC 4916, June 2007.
[8] Rosenberg, J. and C. Jennings, "The Session Initiation [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008. Protocol (SIP) and Spam", RFC 5039, January 2008.
[9] Peterson, J., Jennings, C., and R. Sparks, "Change Process [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real- for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67, RFC time Applications and Infrastructure Area", BCP 67, RFC
5727, March 2010. 5727, March 2010.
[10] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
"Secure Call Origin Identification", draft-cooper-iab- of Named Entities (DANE) Transport Layer Security (TLS)
secure-origin-00 (work in progress), November 2012. Protocol: TLSA", RFC 6698, August 2012.
[11] Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", draft-peterson-sipping-
retarget-00 (work in progress), February 2005.
[12] Rosenberg, J., "Concerns around the Applicability of RFC
4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in
progress), February 2008.
[13] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013.
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002.
[15] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on [TDOS] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on
Public Emergency Networks", URL: Public Emergency Networks", URL:
http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos- http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-
extortion-attacks-on-public-emergency-networks/, Apr 2013. extortion-attacks-on-public-emergency-networks/, Apr 2013.
[16] FCC, , "Robocalls", URL: [news-hack]
http://www.fcc.gov/guides/robocalls, Apr 2013. Wikipedia, , "News International phone hacking scandal",
URL: http://en.wikipedia.org/wiki/
News_International_phone_hacking_scandal, Apr 2013.
[17] FTC, , "FTC Robocall Challenge", URL: [robocall-competition]
FTC, , "FTC Robocall Challenge", URL:
http://robocall.challenge.gov/, Apr 2013. http://robocall.challenge.gov/, Apr 2013.
[18] Wikipedia, , "News International phone hacking scandal", [robocall-fcc]
URL: http://en.wikipedia.org/wiki/ FCC, , "Robocalls", URL:
News_International_phone_hacking_scandal, Apr 2013. http://www.fcc.gov/guides/robocalls, Apr 2013.
[19] Wikipedia, , "Don't Make the Call: The New Phenomenon of [swatting]
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
 End of changes. 63 change blocks. 
276 lines changed or deleted 316 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/