idnits 2.17.1 draft-cooper-iab-secure-origin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 30, 2012) is 4165 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cooper 3 Internet-Draft CDT 4 Intended status: Informational H. Tschofenig 5 Expires: June 3, 2013 Nokia Siemens Networks 6 J. Peterson 7 NeuStar 8 B. Aboba 9 Microsoft 10 November 30, 2012 12 Secure Call Origin Identification 13 draft-cooper-iab-secure-origin-00.txt 15 Abstract 17 A number of parties have suggested creating mandates such that 18 networks receiving voice calls would be capable of securely 19 identifying the call origin. This document provides insights about 20 the capabilities and limitations of supporting call origin 21 identification in a secure and privacy- friendly way in the PSTN and 22 for IP-based real-time communications. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 3, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Secure Origin Challenges in the PSTN . . . . . . . . . . . . . 3 60 3. Secure Origin Challenges for VoIP . . . . . . . . . . . . . . . 4 61 4. Secure Origin Challenges for Real-Time Communication on 62 the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 A number of parties have suggested creating mandates such that 71 networks receiving voice calls would be capable of securely 72 identifying the call origin [TD-62]. These proposals are primarily 73 motivated by concerns over fraudulent calls and the associated 74 economic impact that spoofed or fraudulent origin identification can 75 have on telecommunications settlement agreements. Concerns have also 76 been raised about ensuring secure origin identification for law 77 enforcement and abuse tracking purposes. 79 Support for caller identification in the public switched telephone 80 network (PSTN) has been developed to meet existing regulatory needs 81 and for other purposes, but it has limitations. As real-time 82 communication has become IP-based, it has become significantly more 83 difficult to identify the origin of real-time communication for a 84 number of reasons. Furthermore, to the extent that new mandates are 85 being suggested to require origin identification for all IP traffic 86 -- real-time or not -- it is unclear how such identification would be 87 accomplished given the complexity and diversity of today's IP network 88 traffic. This document provides insights about the capabilities and 89 limitations of supporting call origin identification in a secure and 90 privacy-friendly way in the PSTN and for IP-based real-time 91 communications. 93 2. Secure Origin Challenges in the PSTN 95 The problems facing origin identification are not limited to the 96 Internet. In the traditional public switched telephone network, 97 information about the calling party is often missing from signaling 98 messages. This is because, per the ITU-T and related national 99 specifications (beginning with Q.761), the calling party number field 100 of a call establishment message (IAM) is an optional parameter. 101 There remain a number of legitimate reasons today why the origin of a 102 telephone call might be absent from call establishment signaling: 103 because of interworking with a legacy (pre-SS7) network or a private 104 branch exchange which lacks the capability to identify subscribers, 105 for example, or because the call has been handled by an interexchange 106 carrier using calling cards that require the customer to dial a relay 107 number. So long as there are legitimate reasons why the calling 108 party number might be missing from a call, and the parameter remains 109 optional in the SS7 standards, carriers will sometimes fail to 110 provide origin identification in the telephone network. Parties who 111 want to obscure their identity can rely on equipment or carriers that 112 do not provide the calling party number. 114 Whether or not the calling party number should be trusted, if it is 115 present, is a separate but related question. Private branch 116 exchanges that signal calls via ISDN (Q.931) can provide an arbitrary 117 calling party number in their own call establishment message (SETUP), 118 and some operators translate those numbers directly to the calling 119 party number field of SS7. Due to the transitive trust inherent in 120 the SS7 network, there is no way for the recipient of a call to 121 determine how trustworthy the calling party number field is: 122 effectively, all carriers in the telephone network necessarily trust 123 the origin identification provided by any carrier. These 124 difficulties have been exacerbated by the widespread deployment of 125 Internet gateways. For these gateways, it is almost always better to 126 supply no calling party number to the SS7 network than it is to 127 accept a number provided by Internet signaling. Because some 128 gateways do accept the numbers provided by Internet callers, however, 129 this further weakens the trustworthiness of calling party number 130 information on the telephone network. These concerns are not limited 131 to calls either: text messages have similar problems resulting from 132 email-to-text gateways. 134 Our ability to solve origin identification for Internet calling 135 depends on solving it for the telephone network, as Internet 136 telephony solutions inevitably exchange traffic with the telephone 137 network. Given the inherent limitations of SS7 standards for origin 138 identification, the transitive trust properties of the telephone 139 network, and the widespread acceptance of calls without origin 140 identification in the telephone system today, the prospects are very 141 doubtful for remedying this problem by simply mandating that carriers 142 provide origin identification. 144 3. Secure Origin Challenges for VoIP 146 Standards for Voice Over IP (VoIP) originally focused on Session 147 Initiation Protocol (SIP) and Extensible Messaging and Presence 148 Protocol (XMPP)-based systems, with SIP becoming a popular foundation 149 for many proprietary VoIP systems. SIP provides a number of 150 different mechanisms for asserting the identity of a caller, 151 including "P-Asserted-Identity" (PAI) [RFC3325], "SIP Cert" [RFC6072] 152 and the "SIP Identity" mechanism [RFC4474]. PAI and SIP Identity 153 allow SIP application servers in the network to insert caller 154 information into the 'From' header of outgoing calls. 156 However, not all calls will necessarily identify the calling party in 157 any way, and there are no standardized requirements to use any 158 particular caller identification solution. Anonymous calls and calls 159 made from outbound-only calling services generally do not contain 160 identity information. In addition, in some situations, calls made 161 through relay services may identify the relay as the calling party 162 rather than the original caller. 164 In addition, the identifier syntax used in SIP varies from email- 165 address-style identifiers to ones that use E.164 telephone numbers. 166 Because of the security shortcomings of the PSTN described above, 167 SIP-based services that seek to make authentication and 168 identification guarantees cannot do so purely with E.164 numbers. 169 Such guarantees would require a universal move toward email-style 170 identifiers. 172 Even in a SIP-only environment, the choice of syntax, made separately 173 by different implementers and users, impacts the security mechanisms 174 that can be used for attesting to the authenticity of the identifier. 175 Without any form of cryptographic identity assertion, the 'From' 176 header can be easily forged, and headers are often stripped or 177 modified by intermediaries in transit. Attempts at enhancing the 178 integrity protection of SIP identity have not seen wide deployment. 180 Finally, SIP supports a number of privacy mechanisms that allow SIP 181 users to shield their identities from the network and the called 182 party [RFC3323] [RFC5767] [RFC5379]. SIP privacy has valid uses; for 183 example, it enables users to avoid exposing their identity to 184 destinations that might make them a target for unsolicited 185 advertising or other undesirable consequences. As in the PSTN, 186 parties that do not wish to disclose their identities can use 187 services that support this functionality. 189 4. Secure Origin Challenges for Real-Time Communication on the Web 191 While SIP and XMPP were originally designed to facilitate 192 interoperable real-time communications between systems developed by 193 different vendors, the last 10 years have seen the rise of a new 194 platform for deployment of applications: the world wide web. Web 195 applications that run in a secure execution environment inside a web 196 browser are now commonplace. As a result, real-time communications 197 -- including voice and video telephony -- are migrating to the web as 198 well. 200 This new trend in application development enables real-time 201 application to be downloaded on-demand and executed within the 202 browser utilizing new interfaces in the browser platform to interact 203 with the microphone, camera, and other sensors. The integration of 204 real-time communication into the huge web ecosystem opens a number of 205 new possibilities that were previously only possible with proprietary 206 browser plug-ins. 208 This migration to the web does not eliminate the challenges 209 associated with providing secure call origin identification; in some 210 ways, it even serves to complicate the situation. While web servers 211 have a common and widely used means of authenticating themselves -- 212 public key-based authentication infrastructure for use with SSL -- no 213 single client-side authentication mechanism has emerged to 214 authenticate users sitting in front of their browsers. Instead, a 215 variety of technologies have been deployed, often with applicability 216 only in narrow sectors. 218 Enterprise networks, for example, often use hardware tokens to 219 authenticate employees. Banking web sites often require one-time 220 secrets in combination with knowledge-based security. Many consumer- 221 focused web sites tend to rely on insecure password-based 222 authentication. With so many web sites requiring authentication, Web 223 Single-Sign-On (WebSSO) deployments have emerged to attempt to create 224 a uniform authentication mechanism. But while individual identity 225 providers offering such WebSSO solutions offer security benefits and 226 great convenience for end users, they too are typically limited as 227 far as the scope of web sites that can rely on them for 228 authentication. Relying web sites, likewise, usually only support a 229 single or limited set of identity providers. Consequently, users are 230 confronted with islands on the web that use different identity 231 technologies. 233 Because web-based real-time applications extends the existing web 234 ecosystem, they also inherit its identity management ecosystem, a 235 system that is still in flux. With new technology being developed 236 every day it is unlikely that a single identity management technology 237 will dominate in the near future. Furthermore, because of the 238 technological differences between web identity management and caller 239 identification in SIP and other previously developed real-time 240 communication technologies, the seamless flow of identity information 241 across these technologies will likely remain elusive for the 242 foreseeable future. 244 5. Conclusion 246 Every calling technology presents significant challenges to the 247 secure identification of the caller. The interoperation of all of 248 these technologies -- from legacy pre-SS7 telephone networks to 249 cutting edge web-based calling services -- further complicates the 250 task of identifying the origin of a call in a trusted and 251 interoperable way. While industry efforts are underway to address 252 some of these challenges, a uniform origin identification system is 253 unlikely to emerge, regardless of potential regulatory mandates. 255 6. Security Considerations 257 This document describes, at a high level, some of the security 258 challenges of providing trustworthy call origin information. There 259 are further detailed privacy and security aspects related to call 260 origin identification that will be addressed in a future version of 261 this document. 263 7. Informative References 265 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 266 Initiation Protocol (SIP)", RFC 3323, November 2002. 268 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 269 Extensions to the Session Initiation Protocol (SIP) for 270 Asserted Identity within Trusted Networks", RFC 3325, 271 November 2002. 273 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 274 Authenticated Identity Management in the Session 275 Initiation Protocol (SIP)", RFC 4474, August 2006. 277 [RFC5379] Munakata, M., Schubert, S., and T. Ohba, "Guidelines for 278 Using the Privacy Mechanism for SIP", RFC 5379, 279 February 2010. 281 [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- 282 Driven Privacy Mechanism for SIP", RFC 5767, April 2010. 284 [RFC6072] Jennings, C. and J. Fischl, "Certificate Management 285 Service for the Session Initiation Protocol (SIP)", 286 RFC 6072, February 2011. 288 [TD-62] Council Working Group to Prepare for the 2012 World 289 Conference on International Telecommunications, "CWG- 290 WCIT12 Temporary Document 62 Rev.2 - Draft Compilation of 291 Proposals with Options for Revisions to the ITRs", 2012, < 292 http://files.wcitleaks.org/public/ 293 T09-CWG.WCIT12-120620-TD-PLEN-0062R2.pdf>. 295 Authors' Addresses 297 Alissa Cooper 298 CDT 299 1634 Eye St. NW, Suite 1100 300 Washington, DC 20006 301 USA 303 Email: acooper@cdt.org 305 Hannes Tschofenig 306 Nokia Siemens Networks 308 Email: hannes.tschofenig@gmx.net 310 Jon Peterson 311 NeuStar 313 Email: jon.peterson@neustar.biz 315 Bernard Aboba 316 Microsoft 318 Email: bernard.aboba@gmail.com