< draft-peterson-secure-origin-ps-01.txt		draft-peterson-secure-origin-ps-02.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: January 16, 2014 Columbia University		Expires: March 08, 2014 Columbia University
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	July 15, 2013		September 04, 2013
	Secure Origin Identification: Problem Statement, Threat Model,		Secure Origin Identification: Problem Statement, Requirements, and
	Requirements, and Roadmap		Roadmap
	draft-peterson-secure-origin-ps-01.txt		draft-peterson-secure-origin-ps-02.txt
	Abstract		Abstract
	Over the past decade, SIP has become a major signaling protocol for		Over the past decade, SIP has become a major signaling protocol for
	voice communications, one which has replaced many traditional		voice communications, one which has replaced many traditional
	telephony deployments. However, interworking SIP with the		telephony deployments. However, interworking SIP with the
	traditional telephone network has ultimately reduced the security of		traditional telephone network has ultimately reduced the security of
	Caller ID systems. Given the widespread interworking of SIP with the		Caller ID systems. Given the widespread interworking of SIP with the
	telephone network, the lack of effective standards for identifying		telephone network, the lack of effective standards for identifying
	the calling party in a SIP session has granted attackers new powers		the calling party in a SIP session has granted attackers new powers
	skipping to change at page 1, line 46 ¶		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 January 16, 2014.		This Internet-Draft will expire on March 08, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 5		3.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 5
	3.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 6		3.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 6
	3.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 7		3.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 7
	3.4. VoIP-to-PSTN Call Call . . . . . . . . . . . . . . . . . 8		3.4. VoIP-to-PSTN Call Call . . . . . . . . . . . . . . . . . 8
	3.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 9		3.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 8
	3.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 9		3.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 9
	4. Limitations of Current Solutions . . . . . . . . . . . . . . 10		4. Limitations of Current Solutions . . . . . . . . . . . . . . 9
	4.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 10		4.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.2. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Environmental Changes . . . . . . . . . . . . . . . . . . . . 15		5. Environmental Changes . . . . . . . . . . . . . . . . . . . . 15
	5.1. Shift to Mobile Communication . . . . . . . . . . . . . . 15		5.1. Shift to Mobile Communication . . . . . . . . . . . . . . 15
	5.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 16		5.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 15
	5.3. Public Key Infrastructure Developments . . . . . . . . . 16		5.3. Public Key Infrastructure Developments . . . . . . . . . 16
	5.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 16		5.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 16
	5.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 17		5.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 17
	5.6. Relationship with Number Assignment and Management . . . 17		5.6. Relationship with Number Assignment and Management . . . 17
	5.7. Threat Model . . . . . . . . . . . . . . . . . . . . . . 18		6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.7.1. Actors . . . . . . . . . . . . . . . . . . . . . . . 19		7. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.7.1.1. Endpoints . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	5.7.1.2. Intermediaries . . . . . . . . . . . . . . . . . 20		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	5.7.1.3. Attackers . . . . . . . . . . . . . . . . . . . . 21		10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	5.7.2. Attacks . . . . . . . . . . . . . . . . . . . . . . . 21		11. Informative References . . . . . . . . . . . . . . . . . . . 19
	5.7.2.1. Voicemail Hacking via Impersonation . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	5.7.2.2. Unsolicited Commercial Calling from Impersonated
	Numbers . . . . . . . . . . . . . . . . . . . . . 22
	5.7.2.3. Attack Scenarios . . . . . . . . . . . . . . . . 23
	5.7.2.4. Solution-Specific Attacks . . . . . . . . . . . . 24
	6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 24
	7. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11. Informative References . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	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 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 arises from the need to implement authorization policies (to		attempt arises 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
	skipping to change at page 16, line 6 ¶		skipping to change at page 16, line 4 ¶
	example, the Apple iMessage service, which allows iPhone users to		example, the Apple iMessage service, which allows iPhone users to
	send SMS messages to one another over the Internet rather than over		send SMS messages to one another over the Internet rather than over
	the PSTN. Like VIPR, iMessage creates an out-of-band connection over		the PSTN. Like VIPR, iMessage creates an out-of-band connection over
	the Internet between iPhones; unlike VIPR, the rendezvous service is		the Internet between iPhones; unlike VIPR, the rendezvous service is
	provided by a trusted centralized database of iPhones rather than by		provided by a trusted centralized database of iPhones rather than by
	a DHT. While Apple's service is specific to customers of its smart		a DHT. While Apple's service is specific to customers of its smart
	phones, it seems clear that similar databases could be provided by		phones, it seems clear that similar databases could be provided by
	neutral third parties in a position to coordinate between endpoints.		neutral third parties in a position to coordinate between endpoints.
	5.2. Failure of Public ENUM		5.2. Failure of Public ENUM
	At the time [1] was written, the hopes for establishing a certificate		At the time [1] was written, the hopes for establishing a certificate
	authority for telephone numbers on the Internet largely rested on		authority for telephone numbers on the Internet largely rested on
	public ENUM deployment. The e164.arpa DNS tree established for ENUM		public ENUM deployment. The e164.arpa DNS tree established for ENUM
	could have grown to include certificates for telephone numbers or at		could have grown to include certificates for telephone numbers or at
	least for number ranges. It is now clear however that public ENUM as		least for number ranges. It is now clear however that public ENUM as
	originally envisioned has little prospect for adoption. That said,		originally envisioned has little prospect for adoption. That said,
	national authorities for telephone numbers are increasingly migrating		national authorities for telephone numbers are increasingly migrating
	their provisioning services to the Internet, and issuing credentials		their provisioning services to the Internet, and issuing credentials
	that express authority for telephone numbers to secure those		that express authority for telephone numbers to secure those
	services. This new class of certificate authority for numbers could		services. These new authorities for numbers could provide to the
	be opened to the public Internet to provide the necessary signatory		public Internet the necessary signatory authority for securing
	authority for securing calling partys' numbers. While these systems		calling partys' numbers. While these systems are far from universal,
	are far from universal, the authors of this draft believe a		the authors of this draft believe that a solution devised for the
	certificate authority can be constructed for the North American		North American Numbering Plan could have applicability to other
	Numbering Plan in a way that numbering authorities for other country		country codes.
	codes could follow.
	5.3. Public Key Infrastructure Developments		5.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 [5] 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
	skipping to change at page 18, line 8 ¶		skipping to change at page 18, line 5 ¶
	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.
	5.7. Threat Model
	The primary enabler of robocalling, vishing and related attacks is
	the capability to impersonate a calling party number. The most stark
	example of these attacks are cases where automated callees on the
	PSTN rely on the calling number as a security measure, for example to
	access a voicemail system. Robocallers use impersonation as a means
	of obscuring identity; while robocallers can, in the ordinary PSTN,
	block (that is, withhold) their caller identity, callees are less
	likely to pick up calls from blocked identities, and therefore
	calling from some number, any number, is prefereable. Robocallers
	however prefer not to call from a number that can trace back to the
	robocaller, and therefore they impersonate numbers that are not
	assigned to them.
	The scope of impersonation in this threat model pertains solely to
	the rendering of a calling telephone number to an end user or
	automaton at the time of call set-up. The primary attack vector is
	therefore one where the attacker contrives for the calling telephone
	number in signaling to be a particular chosen number, one that the
	attacker does not have the authority to call from, in order for that
	number to be rendered on the terminating side. The threat model
	assumes that this attack simply cannot be prevented: there is no way
	to stop the attacker from creating calls that contain attacker-chosen
	calling telephone numbers in their signaling. The solution space
	therefore focuses on ways that terminating or intermediary elements
	might differentiate authorized from unauthorized calling party
	numbers, in order that policies, human or automatic, might act on
	that information.
	Rendering an authenticated calling party number during call set-up
	time does not entail anything about the entity or entities that will
	send and receive media during the call itself. In call paths with
	intermediaries and gateways as described below, there may be no way
	to provide any assurance in the signaling about participants in the
	media. In those end-to-end IP environments where such an assurance
	is possible, it is highly desirable, but in the threat model
	considered in this document, the threat of impersonation does not
	extend to impersonating an authorized listener after a call has been
	completed. Attackers that could impersonate an authorized listener
	require powers that robocallers and voicemail hackers are unlikely to
	possess, and historically such attacks have not played a role in
	enabling robocalling or related problems.
	In protocols like SIP, call signaling can be renegotiated after the
	call has been completed, and through various transfer mechanisms
	common in telephone systems, callees can easily be connected to, or
	conferenced in with, telephone numbers other than the original
	calling number once a call has been set up. These post-setup changes
	to the call are outside the scope of impersonation considered in this
	model. Furthermore, impersonating a reached number to the originator
	of a call is outside the scope of this threat model.
	In much of the PSTN, there exists a supplemental service that
	translates calling party numbers into regular names, including the
	proper names of people and businesses, for rendering to the called
	user. These services (frequently termed 'Caller ID') provide a
	further attack surface for impersonation. The threat model explored
	in this document focuses only on the calling party number, though
	presenting a forged calling party number can let the attacker cause a
	forged 'Caller ID' name to be rendered to the user as well.
	Providing a verifiable calling party number therefore does improve
	the security of Caller ID systems, but this threat model does not
	consider attacks specific to Caller ID, such as attacks on the
	databases consulted by the terminating side of a call to provide
	Caller ID, or impersonators choosing to forge a particular calling
	party number in order to present a misleading Caller ID to the user.
	Finally, the scope of impersonation in this threat model does not
	consider simple anonymity as a threat. The ability to place
	anonymous calls has always been a feature of the PSTN, and users of
	the PSTN today have the capability to reject anonymous calls should
	they wish to.
	5.7.1. Actors
	5.7.1.1. Endpoints
	There are two main categories of end-user terminals, a dumb device
	(such as a 'black phone') or a smart device:
	Dumb devices comprise a simple dial pad, handset and ringer,
	optionally accompanied by a display that can show only a limited
	number of characters (typically, enough for a telephone number and
	an accompanying name, sometimes less). These devices are
	controlled by service providers in the network.
	Smart devices are general purpose computers with some degree of
	programmability and the capacity to access the Internet, along
	with a rich display. This includes smart phones, telephone
	applications on desktop and laptop computers, IP private branch
	exchanges, and so on.
	There are also various hybrid devices, such as terminal adapters
	which attach dumb devices to a VoIP service, but which may in turn
	use auxiliary screens as displays for rich information (for example,
	some cable deployments use the television screen to render caller
	ID). These devices expose little programmability to end users.
	There is a further category of automated terminals without an end
	user. These include systems like voicemail services that consume the
	calling party number without rendering it to a human. Though the
	capability of voicemail services varies widely, many today have
	Internet access and advanced application interfaces (to render
	'visual voicemail,' to automatically transcribe voicemail to email,
	and so on).
	5.7.1.2. Intermediaries
	We assume that a call between two endpoints traverses a call path.
	The length of the call path can vary considerably: it is possible in
	VoIP deployments for two endpoint entities to send traffic to one
	another directly, but more commonly several intermediaries exist in a
	VoIP call path. One or more gateways may also appear on a call path.
	Intermediaries forward call signaling to the next entity in the
	path. These intermediaries may also modify the signaling in order
	to improve interoperability, to enable proper network-layer media
	connections, or to enforce operator policy. This threat model
	assumes there are no restrictions on the modifications to
	signaling that an intermediary can introduce.
	Gateways translate call signaling from one protocol into another.
	In the process, they tend to consume any signaling specific to the
	original protocol (elements like transaction-matching identifiers)
	and may need to transcode or otherwise alter identifiers as they
	are rendered in the destination protocol.
	The threat model assumes that intermediaries and gateways can forward
	and retarget calls as necessary, which can result in a call
	terminating at a place the originator did not expect, and that this
	is an ordinary condition in call routing. This is significant to the
	solution space, however, because it limits the ability of the
	originator to anticipate what the telephone number of the respondent
	will be.
	Furthermore, we assume that some intermediaries or gateways may, due
	to their capabilities or policies, discard calling party number
	information, as a whole or in part. Today, many IP-PSTN gateways
	simply ignore any information available about the caller in the IP
	leg of the call, and allow the telephone number of the PRI line that
	the gateway happens to use to be sent as the calling party number for
	the PSTN leg of the call. A call might also gateway to a
	multifrequency network where only a limit number of digits of
	automatic numbering identification (ANI) data are signaled, for
	example. Some protocols may render telephone numbers in a way that
	makes it impossible for a terminating side to parse or canonicalize a
	number. In these cases, providing authenticated identity may be
	impossible. This is not however indicative of an attack or other
	security failure.
	5.7.1.3. Attackers
	We assume that an attacker has the following powers:
	The attacker can create telephone calls at will, originating them
	on either the PSTN or over IP, and can supply an arbitrary calling
	party number.
	The attacker can capture and replay signaling previously received.
	[TBD: should this include a passive attacker that can capture
	signaling that isn't directly sent to it? Not a factor for
	robocalling, but perhaps for voicemail hacking, say.]
	The attacker has access to the Internet, and thus the ability to
	inject arbitrary traffic over the Internet, to access public
	directories, and so on.
	There are many potential threats in which an attacker compromises
	intermediaries in the call path, or captures credentials that allow
	the attacker to impersonate a target. Those system-level threats are
	not considered in this threat model, though secure design of systems
	to prevent these sorts of attacks is necessary for any of these
	countermeasures to work.
	This threat model also does not consider a case in which the
	operators of intermediaries or gateways are themselves adversaries
	who intentionally suppress identity or send falsified identity with
	their own credentials.
	5.7.2. Attacks
	5.7.2.1. Voicemail Hacking via Impersonation
	A voicemail service allows users calling from their mobile phones
	access to their voicemail boxes on the basis of the calling party
	number. An attacker wants to access the voicemail of a particular
	target. The attacker therefore impersonates the calling party number
	using one of the scenarios described below.
	In all cases, the countermeasure to this threat is for the voicemail
	service to have an expectation that calls to its service will supply
	an authenticated identity, and in the absence of that identity, for
	it to adopt a different policy (perhaps requiring a shared secret to
	be dialed as a PIN). Authenticated identity alone provides a
	positive confirmation only when an identity is claimed legitimately;
	the absence of authenticated identity here is not evidence of malice,
	just of uncertainty.
	If the voicemail service could know ahead of time that it should
	always expect authenticated identity from a particular number, that
	would enable the voicemail service to adopt different policies for
	handling a request without authenticated identity. Since users
	contact a voicemail service repeatedly, this is something that a
	voicemail server could learn, for example, the first time that a user
	contacts it. Alternatively, it could access a directory of some kind
	that informs verifiers that they should expect identity from
	particular numbers.
	5.7.2.2. Unsolicited Commercial Calling from Impersonated Numbers
	The unsolicited commercial calling, or for short robocalling, threat
	is similar to the voicemail threat, except in so far as the
	robocaller does not need to impersonate any specific number, merely a
	plausible number. A robocaller may impersonate a number that is not
	a valid number (for example, in the United States, a number beginning
	with 0), or an unassigned number. The robocaller may change numbers
	every time a new call is placed, even selecting numbers randomly.
	The countermeasures to robocalling are similar to the voicemail
	example, but there are significant differences. One important
	potential countermeasure is simply to verify that the calling party
	number is in fact valid and assigned. Unlike voicemail services, end
	users typically have never been contacted by the number used by a
	robocaller before, so they can't rely on past association to know
	whether or not the calling party number should always supply
	authenticated identity. If there were a directory that could inform
	the terminating side of that fact, however, that would help in the
	robocalling case.
	When alerting a human is involved, the time frame for executing these
	countermeasures is necessarily limited. Ideally, a user would not be
	alerted that a call has been received until any necessary identity
	checks have been performed. This could however result in inordinate
	post-dial delay from the perspective of legitimate callers.
	Cryptographic operations and network operations must be minimized for
	these countermeasures to be practical.
	The eventual effect of these countermeasures would be to force
	robocallers to either block their caller identity, in which case end
	users could opt not to receive their calls, or to use authenticated
	identity for numbers traceable to them, which would then allow for
	other forms of redress.
	5.7.2.3. Attack Scenarios
	Impersonation, IP-PSTN
	An attacker on the Internet uses a commercial WebRTC service to send
	a call to the PSTN with a chosen calling party number. The service
	contacts an Internet-to-PSTN gateway, which inserts the attacker's
	chosen calling party number into the CPN field of an IAM. When the
	IAM reaches the endpoint terminal, the terminal renders the
	attacker's chosen calling party number as the calling identity.
	Countermeasure: out-of-band authenticated identity
	Impersonation, PSTN-PSTN
	An attacker with a traditional PBX (connected to the PSTN through an
	ISDN PRI) sends a Q.931 SETUP request with a chosen calling party
	number which a service provider inserts into the corresponding SS7
	CPN field of an IAM. When the IAM reaches the endpoint terminal, the
	terminal renders the attacker's chosen calling party number as the
	calling identity.
	Countermeasure: out-of-band authenticated identity
	Impersonation, IP-IP
	An attacker with an IP phone sends a SIP request to an IP-enabled
	voicemail service. The attacker puts a chosen calling party number
	into the From header field value of the INVITE. When the INVITE
	reaches the endpoint terminal, the terminal renders the attacker's
	chosen calling party number as the calling identity.
	Countermeasure: in-band authenticated identity
	Impersonation, IP-PSTN-IP
	An attacker with an IP phone sends a SIP request to the telephone
	number of a voicemail service, perhaps without even knowing that the
	voicemail service is IP-based. The attacker puts a chosen calling
	party number into the From header field value of the INVITE. The
	attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts
	the attacker's chosen calling party number into the CPN field of an
	IAM. That IAM then traverses the PSTN until (perhaps after a call
	forwarding) it reaches another gateway, this time back to the IP
	realm, to an H.323 network. The PSTN-IP gateway puts takes the
	calling party number in the IAM CPN field and puts it into the SETUP
	request. When the SETUP reaches the endpoint terminal, the terminal
	renders the attacker's chosen calling party number as the calling
	identity.
	Countermeasure: out-of-band authenticated identity
	5.7.2.4. Solution-Specific Attacks
	[TBD: This is just forward-looking notes]
	Threats Against In-band
	Token replay
	Removal of in-band signaling features
	Threats Against Out-of-Band
	Provisioning Gargbage CPRs
	Data Mining
	Threats Against Either Approach
	Attack on directories/services that say whether you should expect
	authenticated identity or not
	Canonicalization attack
	6. Requirements		6. Requirements
	This section describes the high level requirements:		This section describes the high level requirements:
	Usability Any validation mechanism must work without human		Usability Any validation mechanism must work without human
	intervention, e.g., CAPTCHA-like mechanisms.		intervention, e.g., 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.
	skipping to change at page 25, line 41 ¶		skipping to change at page 19, line 5 ¶
	SIP request body. This approach addresses the case where		SIP request body. This approach addresses the case where
	intermediaries do not remove header fields.		intermediaries do not remove header fields.
	Out-of-Band Caller-ID Verification: This functionality determines		Out-of-Band Caller-ID Verification: This functionality determines
	whether the E.164 number used by the calling party actually		whether the E.164 number used by the calling party actually
	exists, the calling entity is entitled to use the number and		exists, the calling entity is entitled to use the number and
	whether a call has recently been made from this phone number.		whether a call has recently been made from this phone number.
	This approach is needed when the in-band technique does not work		This approach is needed when the in-band technique does not work
	due to intermediaries or due to interworking with PSTN networks.		due to intermediaries or due to interworking with PSTN networks.
	Certificate Delegation Infrastructure: This functionality defines		Authority Delegation Infrastructure: This functionality defines how
	how certificates with E.164 numbers are used in number		existing authority over E.164 numbers are used in number
	portability, and delegation cases. It also describes how the		portability, and delegation cases. It also describes how the
	existing numbering infrastructure is re-used to maintain the		existing numbering infrastructure is re-used to maintain the
	lifecycle of number assignments.		lifecycle of number assignments.
	Extended Validation: This functionality describes how to describes		Extended Validation: This functionality describes how to describes
	attributes of the calling party beyond the caller-id and these		attributes of the calling party beyond the caller-id and these
	attributes (e.g., the calling party is a bank) need to be verified		attributes (e.g., the calling party is a bank) need to be verified
	upfront.		upfront.
	8. Acknowledgments		8. Acknowledgments
	skipping to change at page 27, line 19 ¶		skipping to change at page 20, line 29 ¶
	[9] Peterson, J., "Retargeting and Security in SIP: A		[9] 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.
	[10] Rosenberg, J., "Concerns around the Applicability of RFC		[10] 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.
	[11] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for		[11] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for
	Session Initiation Protocol (SIP) Back-to- Back User		Session Initiation Protocol (SIP) Back-to- Back User
	Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-00		Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-01
	(work in progress), April 2013.		(work in progress), August 2013.
	[12] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-		[12] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
	Huguenin, "Verification Involving PSTN Reachability:		Huguenin, "Verification Involving PSTN Reachability:
	Requirements and Architecture Overview", draft-jennings-		Requirements and Architecture Overview", draft-jennings-
	vipr-overview-04 (work in progress), February 2013.		vipr-overview-04 (work in progress), February 2013.
	[13] Rosenberg, J. and H. Schulzrinne, "Session Initiation		[13] 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.
End of changes. 15 change blocks.
	360 lines changed or deleted		29 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/