< draft-ietf-stir-problem-statement-02.txt   draft-ietf-stir-problem-statement-03.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 17, 2014 Columbia University Expires: July 29, 2014 Columbia University
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
January 13, 2014 January 25, 2014
Secure Telephone Identity Problem Statement Secure Telephone Identity Problem Statement
draft-ietf-stir-problem-statement-02.txt draft-ietf-stir-problem-statement-03.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 July 17, 2014. This Internet-Draft will expire on July 29, 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 3, line 16 skipping to change at page 3, line 16
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 for identifying the originating party that
initiates a call or a messaging interaction arises. The desire for initiates a call or a messaging interaction arises. The desire for
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) [4] 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 conceptually 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 [11] 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 30 skipping to change at page 4, line 30
easily act as customers, originating and transit providers. The easily act as customers, originating and transit providers. The
problem is moreover not limited to voice communications, as growth in problem is moreover not limited to voice communications, as growth in
text messaging has made it another vector for bulk unsolicited text messaging has made it another vector for bulk unsolicited
commercial messaging relying on impersonation of a source telephone commercial messaging relying on impersonation of a source telephone
number (sometimes a short code). For telephony, Caller ID spoofing number (sometimes a short code). For telephony, Caller ID spoofing
has become common, with a small subset of entities either ignoring has become common, with a small subset of entities either ignoring
abuse of their services or willingly serving to enable fraud and abuse of their services or willingly serving to enable fraud and
other illegal behavior. other illegal behavior.
For example, recently, enterprises and public safety organizations For example, recently, enterprises and public safety organizations
[17] have been subjected to telephony denial-of-service attacks. In [15] 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 [18] on (automated telemarketing, see, for example, the FCC webpage [16] on
this topic). Robocalls is a problem that has been recognized already this topic). Robocalls are a problem that has been recognized
by various regulators, for example the Federal Tde Commission (FTC) already by various regulators; for example, the Federal Trade
recently organized a robocall competition to solicit ideas for Commission (FTC) recently organized a robocall competition to solicit
creating solutions that will block illegal robocalls [19]. Criminals ideas for creating solutions that will block illegal robocalls [17].
may also use number spoofing to impersonate banks or bank customers Criminals may also use number spoofing to impersonate banks or bank
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 [21]). Some voicemail systems can be set up so that ("swatting", see [19]). 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 [20] has also gained a lot of press attention phone-hacking scandal [18] 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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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 any
other entity, and the recipient of a forwarded message has little 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
Also, in some cases, third parties may need to temporarily use the (see [11]. Also, in some cases, third parties may need to
identity of another individual or organization, with full consent of temporarily use the identity of another individual or organization,
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.
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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 [8]. sip:12125551234@example.com) or as a tel URI [7].
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 11, line 46 skipping to change at page 11, line 46
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 [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 [4], 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. An overview of addressing spam in -Asserted-Identity information. An overview of addressing spam in
SIP, and explaining how it differs from simiilar problems with email, SIP, and explaining how it differs from simiilar problems with email,
appeared in [9]. appeared in [8].
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) [15]. SIP [1] and Verification Involving PSTN Reachability (VIPR) [13]. 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.
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 [5] provides a way for The P-Asserted-Identity header field of SIP [4] provides a way for
trusted network entities to share with one another an authoritative trusted network entities to share with one another an authoritative
identifier for the originator of a call. The value of P-Asserted- identifier for the originator of a call. The value of P-Asserted-
Identity cannot be populated by a user, though if a user wants to Identity cannot be populated by a user, though if a user wants to
suggest an identity to the trusted network, a separate header (P suggest an identity to the trusted network, a separate header (P
-Preferred-Identity) enables them to do so. The features of the P -Preferred-Identity) enables them to do so. The features of the P
-Asserted-Identity header evolved as part of a broader effort to -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 [4]. Any requires the existence of a trust domain as described in [3]. Any
entity in the trust domain may add a P-Asserted-Identity header to a entity in the trust domain may add a P-Asserted-Identity header to a
SIP message, and any entity in the trust domain may forward a message SIP message, and any entity in the trust domain may forward a message
with a P-Asserted-Identity header to any other entity in the trust with a P-Asserted-Identity header to any other entity in the trust
domain. If a trusted entity forwards a SIP request to an untrusted domain. If a trusted entity forwards a SIP request to an untrusted
entity, however, the P-Asserted-Identity header must first be entity, however, the P-Asserted-Identity header must first be
removed; most sorts of end user devices are outside trust domains. 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
skipping to change at page 13, line 30 skipping to change at page 13, line 30
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 [5] was written, the whole notion of P- headers intended for Since [4] was written, the whole notion of P- headers intended for
use in private SIP domains has also been deprecated (see [10], use in private SIP domains has also been deprecated (see [9], largely
largely because of overwhelming evidence that these headers were because of overwhelming evidence that these headers were being used
being used outside of private contexts and leaking into the public outside of private contexts and leaking into the public Internet. It
Internet. It is unclear how many deployments that make use of P is unclear how many deployments that make use of P-Asserted-Identity
-Asserted-Identity in fact conform with the Spec-T requirements of in fact conform with the Spec-T requirements of RFC3324.
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
skipping to change at page 15, line 24 skipping to change at page 15, line 24
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 [13]. 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 [16], requests transit multiple intermediate policies dissimilar to [14], 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 20, line 12 skipping to change at page 20, line 12
American Numbering Plan could have applicability to other country American Numbering Plan could have applicability to other 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 [5] 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
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.
skipping to change at page 23, line 16 skipping to change at page 23, line 16
[1] Peterson, J. and C. Jennings, "Enhancements for [1] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [2] 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] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [3] Watson, M., "Short Term Requirements for Network Asserted
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[4] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002. Identity", RFC 3324, November 2002.
[5] Jennings, C., Peterson, J., and M. Watson, "Private [4] 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.
[6] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [5] 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 [6] 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 [7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004. 3966, December 2004.
[9] Rosenberg, J. and C. Jennings, "The Session Initiation [8] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008. Protocol (SIP) and Spam", RFC 5039, January 2008.
[10] Peterson, J., Jennings, C., and R. Sparks, "Change Process [9] 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.
[11] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, [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.
[12] 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.
[13] 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.
[14] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for [13] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Session Initiation Protocol (SIP) Back-to- Back User
Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-03
(work in progress), December 2013.
[15] 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-06 (work in progress), December 2013. vipr-overview-06 (work in progress), December 2013.
[16] Rosenberg, J. and H. Schulzrinne, "Session Initiation [14] 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.
[17] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on [15] 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.
[18] FCC, , "Robocalls", URL: [16] FCC, , "Robocalls", URL:
http://www.fcc.gov/guides/robocalls, Apr 2013. http://www.fcc.gov/guides/robocalls, Apr 2013.
[19] FTC, , "FTC Robocall Challenge", URL: [17] FTC, , "FTC Robocall Challenge", URL:
http://robocall.challenge.gov/, Apr 2013. http://robocall.challenge.gov/, Apr 2013.
[20] Wikipedia, , "News International phone hacking scandal", [18] 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.
[21] Wikipedia, , "Don't Make the Call: The New Phenomenon of [19] 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
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
 End of changes. 41 change blocks. 
65 lines changed or deleted 54 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/