Public Safety Answering Point (PSAP) Callback
draft-ietf-ecrit-psap-callback-08
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7090.
|
|
|---|---|---|---|
| Authors | Henning Schulzrinne , Hannes Tschofenig , Christer Holmberg , Milan Patel | ||
| Last updated | 2013-02-25 | ||
| Replaces | draft-schulzrinne-ecrit-psap-callback | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-10)
by Vijay Gurbani
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7090 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ecrit-psap-callback-08
5. Security Considerations 5.1. Security Threat The PSAP callback functionality described in this document allows marked calls to bypass blacklists, ignore call forwarding procedures and similar features to contact emergency callers and to raise their attention. Regarding the latter aspect a callback, if understood by the SIP UA would allow to override user interface configurations, such as vibrate-only mode, to alert the caller of the incoming call. 5.2. Security Requirements The requirement is to ensure that the mechanisms described in this document can not be used for malicious purposes, including telemarketing. Furthermore, if the newly defined extension is not recognized, not verified adequately, or not obeyed by SIP intermediaries or SIP endpoints then it must not lead to a failure of the call handling procedure. Such call must be treated like a call that does not have any marking attached. 5.3. Security Solution Figure 7 shows the architecture that utilizes the identity of the PSAP to decide whether a preferential treatment of callbacks should be provided. To make this policy decision the identity of the PSAP is compared with a whitelist of valid PSAPs available to the SIP 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. Schulzrinne, et al. Expires August 29, 2013 [Page 13] Internet-Draft PSAP Callback February 2013 +----------+ | List of |+ | valid || | PSAPs || +----------+| +----------+ * * whitelist * V Incoming +----------+ Normal SIP Msg | SIP |+ Treatment -------------->| Entity ||======================> + Identity | ||(if not in whitelist) Info +----------+| +----------+ || || || Preferential || Treatment ++========================> (if successfully verified) Figure 7: Identity-based Authorization An important aspect from a security point of view is the relationship between the emergency services network (containing PSAPs) and the VSP (assuming that the emergency call travels via the VSP and not directly between the SIP UA and the PSAP). If there is some form of relationship between the emergency services operator and the VSP then the identification of a PSAP call back is less problematic than in the case where the two entities have not entered in some form of relationship that would allow the VSP to verify whether the marked callback message indeed came from a legitimate source. The establishment of a whitelist with PSAP identities maybe be operationally complex. When there is a local relationship between the VSP/ASP and the PSAP then populating the whitelist is fairly simple. For SIP UAs there is no need to maintain a list of PSAPs. Instead SIP UAs are assumed to trust the correct processing of their 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. Schulzrinne, et al. Expires August 29, 2013 [Page 14] Internet-Draft PSAP Callback February 2013 6. IANA Considerations This document adds the "psap-callback" value to the SIP Priority header IANA registry allocated by [I-D.ietf-sipcore-priority]. The semantic of the newly defined "psap-callback" value is defined in Section 4. Schulzrinne, et al. Expires August 29, 2013 [Page 15] Internet-Draft PSAP Callback February 2013 7. Acknowledgements We would like to thank members from the ECRIT working group, in 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 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. We would like to thank the following persons for their feedback on the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly, Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn Schulzrinne, et al. Expires August 29, 2013 [Page 16] Internet-Draft PSAP Callback February 2013 8. References 8.1. Normative References [I-D.ietf-sipcore-priority] Roach, A., "IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field", draft-ietf-sipcore-priority-00 (work in progress), December 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., 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 M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [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. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. Schulzrinne, et al. Expires August 29, 2013 [Page 17] Internet-Draft PSAP Callback February 2013 8.2. Informative References [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", draft-ietf-ecrit-phonebcp-20 (work in progress), September 2011. [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, "Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)", RFC 4484, August 2006. [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well- Known Services", RFC 5031, January 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, 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. Schulzrinne, et al. Expires August 29, 2013 [Page 18] Internet-Draft PSAP Callback February 2013 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: christer.holmberg@ericsson.com Milan Patel InterDigital Communications EMail: Milan.Patel@interdigital.com Schulzrinne, et al. Expires August 29, 2013 [Page 19]