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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/