< draft-ietf-ecrit-psap-callback-05.txt		draft-ietf-ecrit-psap-callback-06.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: March 16, 2013 Nokia Siemens Networks		Expires: April 25, 2013 Nokia Siemens Networks
	C. Holmberg		C. Holmberg
	Ericsson		Ericsson
	M. Patel		M. Patel
	InterDigital Communications		InterDigital Communications
	September 12, 2012		October 22, 2012
	Public Safety Answering Point (PSAP) Callback		Public Safety Answering Point (PSAP) Callback
	draft-ietf-ecrit-psap-callback-05.txt		draft-ietf-ecrit-psap-callback-06.txt
	Abstract		Abstract
	After an emergency call is completed (either prematurely terminated		After an emergency call is completed (either prematurely terminated
	by the emergency caller or normally by the call taker) it is possible		by the emergency caller or normally by the call taker) it is possible
	that the call taker feels the need for further communication. For		that the call taker feels the need for further communication. For
	example, the call may have been dropped by accident without the call		example, the call may have been dropped by accident without the call
	taker having sufficient information about the current situation of a		taker having sufficient information about the current situation of a
	wounded person. A call taker may trigger a callback towards the		wounded person. A call taker may trigger a callback towards the
	emergency caller using the contact information provided with the		emergency caller using the contact information provided with the
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	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 March 16, 2013.		This Internet-Draft will expire on April 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . . 6		3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 6		3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 7
	3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 7		3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 8
	3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 8		3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Network-based Service URN Resolution . . . . . . . . . . . 10		3.4. Network-based Service URN Resolution . . . . . . . . . . . 11
	3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 11		3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 12
	4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12		4. SIP PSAP Callback Indicator . . . . . . . . . . . . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 16		4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 17		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Alternative Solutions Considered . . . . . . . . . . 19		5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 14
	A.1. Identity-based Authorization . . . . . . . . . . . . . . . 19		5.2. Security Requirements . . . . . . . . . . . . . . . . . . 14
	A.2. Trait-based Authorization . . . . . . . . . . . . . . . . 20		5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 14
	A.3. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 21		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
			8.2. Informative References . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Summoning police, the fire department or an ambulance in emergencies		Summoning police, the fire department or an ambulance in emergencies
	is one of the fundamental and most-valued functions of the telephone.		is one of the fundamental and most-valued functions of the telephone.
	As telephone functionality moves from circuit-switched telephony to		As telephone functionality moves from circuit-switched telephony to
	Internet telephony, its users rightfully expect that this core		Internet telephony, its users rightfully expect that this core
	functionality will continue to work at least as well as it has for		functionality will continue to work at least as well as it has for
	the legacy technology. New devices and services are being made		the legacy technology. New devices and services are being made
	available that could be used to make a request for help, which are		available that could be used to make a request for help, which are
	skipping to change at page 12, line 5 ¶		skipping to change at page 13, line 5 ¶
	| SIP |		| SIP |
	| UA |		| UA |
	| Alice |		| Alice |
	+-------+		+-------+
	Figure 5: Example for PSTN Interworking		Figure 5: Example for PSTN Interworking
	Note: This scenario is considered outside the scope of this document.		Note: This scenario is considered outside the scope of this document.
	The specified solution does not support this use case.		The specified solution does not support this use case.
	4. Specification		4. SIP PSAP Callback Indicator
	[Editor's Note: The specification for a solution that meets the		4.1. General
	requirements will be placed in here.]
	5. Security Considerations		This section defines a new header field value, called "psap-
			callback", for the SIP Priority header field defined in [RFC3261].
			The value is used to inform SIP entities that the request is
			associated with a PSAP callback SIP session.
	[Editor's Note: Instead of an abstract security description text will		4.2. Usage
	be provided with the solution description.]
	6. IANA Considerations		SIP entities that receive the header field value within an initial
			request for a SIP session can, depending on local policies, apply
			PSAP callback specific procedures for the session or request.
	[Editor's Note: IANA consideration text will be added once an		The PSAP callback specific procedures may be applied by SIP-based
	agreement on the solution has been reached.		network entities and by the callee. The specific procedures taken
			when receiving such a PSAP callback marked call, such as bypassing
			services and barring procedures, are outside the scope of this
			document.
	7. Acknowledgements		4.3. Syntax
	We would like to thank members from the ECRIT working group, in		4.3.1. General
	particular Brian Rosen, for their discussions around PSAP callbacks.
	The working group discussed the topic of callbacks at their virtual
	interim meeting in February 2010 and the following persons provided
	valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith
	Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,
	Janet Gunn.
	At IETF#81 a small group of people got to together to continue the		This section defines the ABNF for the new SIP Priority header field
	discussions started at the working group meeting to explore a GRUU-		value "psap-callback".
	based solution approach. Martin Thomson, Marc Linsner, Andrew Allen,
	Brian Rosen, Martin Dolly, and Atle Monrad participated at this side-
	meeting.
	Finally, we would like to thank Cullen Jennings for his discussion		4.3.2. ABNF
	input. He was the first to propose a "token-based" solution.
	8. References		priority-value /= "psap-callback"
	8.1. Normative References		Figure 6: ABNF
	[RFC2119] Bradner, S., "Key words for use		5. Security Considerations
	in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119,
	March 1997.
	[RFC3261] Rosenberg, J., Schulzrinne, H.,		5.1. Security Threat
	Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R.,
	Handley, M., and E. Schooler,
	"SIP: Session Initiation
	Protocol", RFC 3261, June 2002.
	[RFC3325] Jennings, C., Peterson, J., and		The PSAP callback functionality described in this document allows
	M. Watson, "Private Extensions		marked calls to bypass blacklists, ignore call forwarding procedures
	to the Session Initiation		and similar features to contact emergency callers and to raise their
	Protocol (SIP) for Asserted		attention. Regarding the latter aspect a callback, if understood by
	Identity within Trusted		the SIP UA would allow to override user interface configurations,
	Networks", RFC 3325,		such as vibrate-only mode, to alert the caller of the incoming call.
	November 2002.
	[RFC3966] Schulzrinne, H., "The tel URI		5.2. Security Requirements
	for Telephone Numbers",
	RFC 3966, December 2004.
	[RFC3969] Camarillo, G., "The Internet		The requirement is to ensure that the mechanisms described in this
	Assigned Number Authority		document can not be used for malicious purposes, including
	(IANA) Uniform Resource		telemarketing.
	Identifier (URI) Parameter
	Registry for the Session
	Initiation Protocol (SIP)",
	BCP 99, RFC 3969,
	December 2004.
	[RFC4474] Peterson, J. and C. Jennings,		Furthermore, if the newly defined extension is not recognized, not
	"Enhancements for Authenticated		verified adequately, or not obeyed by SIP intermediaries or SIP
	Identity Management in the		endpoints then it must not lead to a failure of the call handling
	Session Initiation Protocol		procedure. Such call must be treated like a call that does not have
	(SIP)", RFC 4474, August 2006.		any marking attached.
	[RFC5341] Jennings, C. and V. Gurbani,		5.3. Security Solution
	"The Internet Assigned Number
	Authority (IANA) tel Uniform
	Resource Identifier (URI)
	Parameter Registry",
	September 2008.
	[RFC5627] Rosenberg, J., "Obtaining and		Figure 7 shows the architecture that utilizes the identity of the
	Using Globally Routable User		PSAP to decide whether a preferential treatment of callbacks should
	Agent URIs (GRUUs) in the		be provided. To make this policy decision the identity of the PSAP
	Session Initiation Protocol		is compared with a whitelist of valid PSAPs available to the SIP
	(SIP)", RFC 5627, October 2009.		entity. The identity assurance in SIP can come in different forms,
			such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].
			The former technique relies on a cryptographic assurance and the
			latter on a chain of trust. Also the usage of TLS between
			neighboring SIP entities may provide useful identity information.
	8.2. Informative References		+----------+
			| List of |+
			| valid ||
			| PSAPs ||
			+----------+|
			+----------+
			*
			* whitelist
			*
			V
			Incoming +----------+ Normal
			SIP Msg | SIP |+ Treatment
			-------------->| Entity ||======================>
			+ Identity | ||(if not in whitelist)
			Info +----------+|
			+----------+
			||
			||
			|| Preferential
			|| Treatment
			++========================>
			(if successfully verified)
	[I-D.holmberg-emergency-callback-id] Holmberg, C., "Session		Figure 7: Identity-based Authorization
	Initiation Protocol (SIP)
	emergency call back
	identification", draft-
	holmberg-emergency-callback-id-
	00 (work in progress),
	October 2011.
	[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best		An important aspect from a security point of view is the relationship
	Current Practice for		between the emergency services network (containing PSAPs) and the VSP
	Communications Services in		(assuming that the emergency call travels via the VSP and not
	support of Emergency Calling",		directly between the SIP UA and the PSAP).
	draft-ietf-ecrit-phonebcp-20
	(work in progress),
	September 2011.
	[I-D.ietf-sip-saml] Tschofenig, H., Hodges, J.,		If there is some form of relationship between the emergency services
	Peterson, J., Polk, J., and D.		operator and the VSP then the identification of a PSAP call back is
	Sicker, "SIP SAML Profile and		less problematic than in the case where the two entities have not
	Binding",		entered in some form of relationship that would allow the VSP to
	draft-ietf-sip-saml-08 (work in		verify whether the marked callback message indeed came from a
	progress), October 2010.		legitimate source.
	[RFC4484] Peterson, J., Polk, J., Sicker,		The establishment of a whitelist with PSAP identities maybe be
	D., and H. Tschofenig, "Trait-		operationally complex. When there is a local relationship between
	Based Authorization		the VSP/ASP and the PSAP then populating the whitelist is fairly
	Requirements for the Session		simple. For SIP UAs there is no need to maintain a list of PSAPs.
	Initiation Protocol (SIP)",		Instead SIP UAs are assumed to trust the correct processing of their
	RFC 4484, August 2006.		VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and,
			if it cannot be verified, the PSAP callback marking is removed. If
			it is left untouched then the SIP UA should assume that it has been
			verified successfully by the VSP/ASP and it should therefore be
			obeyed.
	[RFC5012] Schulzrinne, H. and R.		6. IANA Considerations
	Marshall, "Requirements for
	Emergency Context Resolution
	with Internet Technologies",
	RFC 5012, January 2008.
	[RFC5031] Schulzrinne, H., "A Uniform		[Editor's Note: There is currently no registry available for the SIP
	Resource Name (URN) for		Priority header. A registry needs to be created and the value
	Emergency and Other Well-Known		defined in this document needs to be added.]
	Services", RFC 5031,
	January 2008.
	[RFC5234] Crocker, D. and P. Overell,		7. Acknowledgements
	"Augmented BNF for Syntax
	Specifications: ABNF", STD 68,
	RFC 5234, January 2008.
	[RFC6444] Schulzrinne, H., Liess, L.,		We would like to thank members from the ECRIT working group, in
	Tschofenig, H., Stark, B., and		particular Brian Rosen, for their discussions around PSAP callbacks.
	A. Kuett, "Location Hiding:		The working group discussed the topic of callbacks at their virtual
	Problem Statement and		interim meeting in February 2010 and the following persons provided
	Requirements", RFC 6444,		valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith
	January 2012.		Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,
			Janet Gunn.
	Appendix A. Alternative Solutions Considered		At IETF#81 a small group of people got to together to continue the
			discussions started at the working group meeting to explore a GRUU-
			based solution approach. Martin Thomson, Marc Linsner, Andrew Allen,
			Brian Rosen, Martin Dolly, and Atle Monrad participated at this side-
			meeting.
	In an attempt to describe the problem and to explore solution		We would like to thank the following persons for their feedback on
	approaches the working group had also investigated alternative		the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert
	approaches. We document them here for completeness. The solutions		Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly,
	fall into three categories: (1) Identity-based authorization, (2)		Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John
	Trait-based authorization, and (3) Call Marking. Even though these		Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn
	solutions are not mutually exclusive we describe them in separate
	sub-sections.
	Beyond the disadvantages listed in each solution category none of		8. References
	them provides the emergency caller with the ability to restrict
	preferential PSAP callback handling to those cases where an earlier
	emergency call was initiated.
	A.1. Identity-based Authorization		8.1. Normative References
	In Figure 6 an interaction is presented that allows a SIP entity to		[RFC2119] Bradner, S., "Key words for use in RFCs to
	make a policy decision whether to bypass installed authorization		Indicate Requirement Levels", BCP 14,
	policies and thereby providing preferential treatment. To make this		RFC 2119, March 1997.
	decision the sender's identity is compared with a whitelist of valid
	PSAPs. The identity assurances in SIP can come in different forms,
	such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].
	The former technique relies on a cryptographic assurance and the
	latter on a chain of trust.
	+----------+		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo,
	| List of |+		G., Johnston, A., Peterson, J., Sparks,
	| valid ||		R., Handley, M., and E. Schooler, "SIP:
	| PSAP ids ||		Session Initiation Protocol", RFC 3261,
	+----------+|		June 2002.
	+----------+
	*
	* whitelist
	*
	V
	Incoming +----------+ Normal
	SIP Msg | SIP |+ Treatment
	-------------->| Entity ||=============>
	+ Identity | ||(if not in whitelist)
	+----------+|
	+----------+
	||
	||
	|| Preferential
	|| Treatment
	++=============>
	(in whitelist)
	Figure 6: Identity-based Authorization		[RFC3325] Jennings, C., Peterson, J., and M. Watson,
			"Private Extensions to the Session
			Initiation Protocol (SIP) for Asserted
			Identity within Trusted Networks",
			RFC 3325, November 2002.
	This approach was not chosen because the establishment of a whitelist		[RFC3966] Schulzrinne, H., "The tel URI for
	containing PSAP identities is operationally complex and does not		Telephone Numbers", RFC 3966,
	easily scale world wide. Only when there is a local relationship		December 2004.
	between the VSP/ASP and the PSAP then populating the whitelist is far
	simpler. This would, however, constrain the applicability of the
	mechanism considerably.
	A.2. Trait-based Authorization		[RFC3969] Camarillo, G., "The Internet Assigned
			Number Authority (IANA) Uniform Resource
			Identifier (URI) Parameter Registry for
			the Session Initiation Protocol (SIP)",
			BCP 99, RFC 3969, December 2004.
	An alternative approach to an identity based authorization model is		[RFC4474] Peterson, J. and C. Jennings,
	outlined in Figure 7. In fact, RFC 4484 [RFC4484] illustrates a		"Enhancements for Authenticated Identity
	related emergency service use case.		Management in the Session Initiation
			Protocol (SIP)", RFC 4474, August 2006.
	+----------+		[RFC5627] Rosenberg, J., "Obtaining and Using
	| List of |+		Globally Routable User Agent URIs (GRUUs)
	| trust ||		in the Session Initiation Protocol (SIP)",
	| anchor ||		RFC 5627, October 2009.
	+----------+|
	+----------+
	*
	*
	*
	V
	Incoming +----------+ Normal
	SIP Msg | SIP |+ Treatment
	-------------->| Entity ||=============>
	+ trait | ||(no indication
	+----------+| of PSAP)
	+----------+
	||
	||
	|| Preferential
	|| Treatment
	++=============>
	(indicated as
	PSAP)
	Figure 7: Trait-based Authorization		8.2. Informative References
	In a trait-based authorization scenario an incoming SIP message		[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current
	contains a form of trait, i.e. some form of assertion. The assertion		Practice for Communications Services in
	contains an indication that the sending party has the role of a PSAP		support of Emergency Calling",
	(or similar emergency services entity). The assertion is either		draft-ietf-ecrit-phonebcp-20 (work in
	cryptographically protected to enable end-to-end verification or an		progress), September 2011.
	chain of trust security model has to be assumed. In Figure 7 we
	assume an end-to-end security model where trust anchors are
	provisioned to ensure the ability for a SIP entity to verify the
	received assertion.
	This solution was not chosen because trait-based authorization never		[RFC4484] Peterson, J., Polk, J., Sicker, D., and H.
	got deployed in SIP. Furthermore, in order to ensure that the		Tschofenig, "Trait-Based Authorization
	assertions are properly protected it is necessary to digitally sign,		Requirements for the Session Initiation
	which requires some form of public key infrastructure for usage with		Protocol (SIP)", RFC 4484, August 2006.
	emergency services. Finally, there need to be some policies in place
	that define which entities are allowed to obtain various roles.
	These policies and procedures do not exist today.
	A.3. Call Marking		[RFC5012] Schulzrinne, H. and R. Marshall,
			"Requirements for Emergency Context
			Resolution with Internet Technologies",
			RFC 5012, January 2008.
	Call marking allows the PSAP to place a non-cryptographic label on		[RFC5031] Schulzrinne, H., "A Uniform Resource Name
	outgoing calls that gives, when received by a SIP entity,		(URN) for Emergency and Other Well-Known
	preferential treatment for these callbacks.		Services", RFC 5031, January 2008.
	When used in isolation this mechanism introduces considerable denial		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF
	of service attacks due to the ability to bypass any authorization		for Syntax Specifications: ABNF", STD 68,
	policies and could be utilized to distribute unwanted traffic.		RFC 5234, January 2008.
			[RFC6444] Schulzrinne, H., Liess, L., Tschofenig,
			H., Stark, B., and A. Kuett, "Location
			Hiding: Problem Statement and
			Requirements", RFC 6444, January 2012.
	Authors' Addresses		Authors' Addresses
	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
End of changes. 51 change blocks.
	241 lines changed or deleted		197 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/