idnits 2.17.1 draft-peterson-stir-rfc4916-update-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-modern-problem-framework' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-modern-teri' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 292, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-03 == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-01 == Outdated reference: A later version (-09) exists of draft-ietf-stir-passport-divert-01 == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-03 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Informational C. Wendt 5 Expires: September 6, 2018 Comcast 6 March 5, 2018 8 Connected Identity for STIR 9 draft-peterson-stir-rfc4916-update-00.txt 11 Abstract 13 The SIP Identity header conveys cryptographic identity information 14 about the originators of SIP requests. The Secure Telephone Identity 15 Revisited (STIR) framework however provides no means for determining 16 the identity of the called party in a traditional telephone calling 17 scenario. This document updates prior guidance on the "connected 18 identity" problem to reflect the changes to SIP Identity that 19 accompanied STIR, and considers a revised problem space for connected 20 identity as a means of detecting calls that have been retargeted to a 21 party impersonating the intended destination. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 6, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Connected Identity Problem Statement for STIR . . . . . . . . 3 60 4. Authorization Policy for Callers . . . . . . . . . . . . . . 4 61 5. Pre-Association with Destinations . . . . . . . . . . . . . . 5 62 6. Updates to RFC4916 . . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 10. Informative References . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 The Session Initiation Protocol (SIP) [RFC3261] initiates sessions, 72 and as a step in establishing sessions, it exchanges information 73 about the parties at both ends of a session. Users review 74 information about the calling party, for example, to determine 75 whether to accept communications initiated by a SIP, in the same way 76 that users of the telephone network assess "Caller ID" information 77 before picking up calls. This information may sometimes be consumed 78 by automata to make authorization decisions. 80 STIR [RFC8224] provides a cryptographic assurance of the identity of 81 calling parties in order to prevent impersonation, which is a key 82 enabler of unwanted robocalls, swatting, vishing, voicemail hacking, 83 and similar attacks (see [RFC7340]). There also exists a related 84 problem: the identity of the party who answers a call can differ from 85 that of the initial called party for various reasons such as call 86 forwarding, call distribution and call pick-up. It can potentially 87 be difficult to determine why a call reaches a target other than the 88 one originally intended, and whether the party ultimately reached by 89 the call is one that the caller should trust 91 [RFC4916] allowed a mid-dialog request, such as an UPDATE [RFC3311], 92 to convey what is commonly called "connected identity" information-- 93 that is, the identity of the connected user--in either direction 94 within the context of an existing INVITE-initiated dialog. In an 95 update to the original [RFC3261] behavior, [RFC4916] allowed that 96 UPDATE to alter the From header field value for requests in the 97 backwards direction: previously [RFC3261] required that the From 98 header field values sent in requests in the backwards direction 99 reflect the To header field value of the dialog-forming request, for 100 various backwards-compatibility reasons. In other words, if Alice 101 sent a dialog-forming request to Bob, then under the original 102 [RFC3261] rules, even if that dialog-forming request reached Carol, 103 Carol would still be required to put Bob's identity in the From 104 header field value in any mid-dialog requests in the backwards 105 direction. [RFC4916] furthermore created the "from-change" option 106 tag to negotiate this capability during dialog establishment. 108 [RFC4916] was created to work with the original SIP Identity 109 [RFC4474] mechanism, as that mechanism only allowed requests to be 110 signed, but not responses. Since a mid-dialog request in the 111 backwards direction can be signed with Identity like any other SIP 112 request, this created a practical problem: Carol, say, would not be 113 able to furnish a key to sign for Bob's identity, if Carol wanted to 114 sign requests in the backwards direction. 116 This specification updates [RFC4916] to reflect the changes to the 117 SIP Identity header as defined in [RFC4474] made by [RFC8224], and 118 the revised problem space of STIR. 120 2. Terminology 122 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 123 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 125 3. Connected Identity Problem Statement for STIR 127 The STIR problem statement [RFC7340] enumerates robocalling, 128 voicemail hacking, vishing, and swatting as problems with the modern 129 telephone number that are enabled, or abetted, by impersonation: by 130 the ability of a calling party to arbitrarily set the identity that 131 will be rendered to end users to identify the caller. 133 Today, sophisticated adversaries can redirect calls on the PSTN to 134 destinations other than the intended called party. For some call 135 centers, like those associated with financial institutions, 136 healthcare, and emergency services, an attacker could hope to gain 137 valuable information about people or to prevent some classes of 138 important services. 140 Moreover, on the Internet, the lack of any centralized or even 141 federated routing system for telephone numbers has resulted in 142 deployments where the routing of calls is arbitrary: calls to a 143 telephone numbers might be unceremoniously dumped on a PSTN gateway, 144 they might be sent to a default intermediary that makes forwarding 145 decisions based on a local flat file, various mechanisms like private 146 ENUM might be consulted, or routing might be determined in some 147 other, domain specific way. While the MODERN framework hopes to 148 foster a more credible story about how to establish authority for 149 telephone numbers on the Internet, in the interim, there are numerous 150 attack surfaces that an adversary could explore to attempt to 151 redirect calls to a particular number to someplace other than the 152 intended destination. 154 [RFC4916] rightly observed that once a SIP call has been answered, 155 the called party can be replaced by a different party with a 156 different identity due to call transfer, call park and retrieval, and 157 so on. In some cases, due to the presence of a back-to-back user 158 agent, it can be effectively impossible for the calling party to know 159 that this has happened. The problem statement considered for STIR 160 focuses solely on call setup, and whether or not media from the 161 connected party should be rendered to the caller when a dialog has 162 been established. This specification does not consider further any 163 threats that arise from a substitution of the called party. 165 4. Authorization Policy for Callers 167 In traditional telephone call, the called party receives an alerting 168 signal and can make a decision about whether or not to pick up a 169 phone. They may have access to displayed information, like "Caller 170 ID", to help them arrive at an authorization decision. The situation 171 is more complicated for callers, however: callers typically expect to 172 be connected to the proper destination and are often holding 173 telephones in a position that would not enable them to see displayed 174 information, if any were available for them to review--and moreover, 175 their most direct response to a security breach would be to hang up 176 the call they were in the middle of placing. 178 While this specification will not prescribe any user experience 179 associated with placing a call, it assumes that callers have some 180 authorization posture that will result in the right thing happening 181 when the connected identity is not expected. This is analogous to a 182 situation where SRTP negotiation fails because the keys exchanges at 183 the media layer do not match fingerprints exchanged at the signaling 184 layer: when a user requests confidentiality services, and they are 185 available, media should not be exchanged. Thus we assume that users 186 have a way in their interface to require this criticality, on a per- 187 call basis, or perhaps on a per-destination basis. Similarly, users 188 will not always place calls where the connected identity is crucial-- 189 but when they do, they should have a way to tell their devices that 190 the call should not be completed if it arrives at an unexpected 191 party. 193 Ultimately, authorization policy for called parties is difficult to 194 set, as calls can end up at unexpected places for legitimate reasons. 195 Some work has been done to make sure that secure diversion works with 196 STIR, in for example [I-D.ietf-stir-passport-divert]. Those 197 indications can be consumed by on the terminating side by 198 verification services to determine that a call has reached its 199 eventual destination for the right reasons. There is currently no 200 way to expose similar information to the calling party however: only 201 if redirection is used (SIP 3XX responses) instead of retargeting 202 will the originating side participate in setting a new destination 203 for calls. 205 Future versions of this specification will explore ways that the 206 results of mechanisms like [I-D.ietf-stir-passport-divert] could be 207 communicated back to the originating authentication service. 209 5. Pre-Association with Destinations 211 Any connected identity mechanism will work best if the user knows 212 before initiating a call that security services are supported by the 213 destination side. Not every institution that a user wants to connect 214 to securely will support STIR and connected identity out of the gate. 216 Future versions of this specification will explore how the security 217 features of destinations can be discovered before calls are set up so 218 that calling parties can make more informed authorization decisions. 219 This may reuse mechanisms defined by [I-D.ietf-stir-oob]. 221 6. Updates to RFC4916 223 [TBD - ways that UPDATEs in the backwards direction can carry 224 additional information in support of the above] 226 In general, the guidance of RFC4916 remains valid for RFC8224. 228 The deprecation of the Identity-Info header has a number of 229 implications for RFC4916; all of the protocol examples need to be 230 updated to reflect that. 232 7. Acknowledgments 234 We would like to thank YOU for your contributions to this 235 specification. 237 8. IANA Considerations 239 This memo includes no request to IANA. 241 9. Security Considerations 243 TBD. 245 10. Informative References 247 [I-D.ietf-modern-problem-framework] 248 Peterson, J. and T. McGarry, "Modern Problem Statement, 249 Use Cases, and Framework", draft-ietf-modern-problem- 250 framework-03 (work in progress), July 2017. 252 [I-D.ietf-stir-oob] 253 Rescorla, E. and J. Peterson, "STIR Out-of-Band 254 Architecture and Use Cases", draft-ietf-stir-oob-01 (work 255 in progress), October 2017. 257 [I-D.ietf-stir-passport-divert] 258 Peterson, J., "PASSporT Extension for Diverted Calls", 259 draft-ietf-stir-passport-divert-01 (work in progress), 260 October 2017. 262 [I-D.peterson-modern-teri] 263 Peterson, J., "An Architecture and Information Model for 264 Telephone-Related Information (TeRI)", draft-peterson- 265 modern-teri-03 (work in progress), July 2017. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 273 A., Peterson, J., Sparks, R., Handley, M., and E. 274 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 275 DOI 10.17487/RFC3261, June 2002, 276 . 278 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 279 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 280 2002, . 282 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 283 Authenticated Identity Management in the Session 284 Initiation Protocol (SIP)", RFC 4474, 285 DOI 10.17487/RFC4474, August 2006, 286 . 288 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 289 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 290 2007, . 292 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 293 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 294 2014, . 296 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 297 Telephone Identity Problem Statement and Requirements", 298 RFC 7340, DOI 10.17487/RFC7340, September 2014, 299 . 301 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 302 "Authenticated Identity Management in the Session 303 Initiation Protocol (SIP)", RFC 8224, 304 DOI 10.17487/RFC8224, February 2018, 305 . 307 Authors' Addresses 309 Jon Peterson 310 Neustar, Inc. 311 1800 Sutter St Suite 570 312 Concord, CA 94520 313 US 315 Email: jon.peterson@neustar.biz 317 Chris Wendt 318 Comcast 319 One Comcast Center 320 Philadelphia, PA 19103 321 USA 323 Email: chris-ietf@chriswendt.net