idnits 2.17.1 draft-ietf-stir-passport-divert-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 5, 2018) is 2241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 402, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 March 5, 2018 5 Expires: September 6, 2018 7 PASSporT Extension for Diverted Calls 8 draft-ietf-stir-passport-divert-02.txt 10 Abstract 12 This document extends PASSporT, which conveys cryptographically- 13 signed information about the people involved in personal 14 communications, to include an indication that a call has been 15 diverted from its original destination to a new one. This 16 information can greatly improve the decisions made by verification 17 services in call forwarding scenarios. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 6, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Nesting the original PASSporT in 'div' . . . . . . . . . 5 57 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 59 4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 60 5. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 7 61 6. Extending 'div' to work with Service Logic Tracking . . . . . 8 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 10. Informative References . . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 71 conveying cryptographically-signed information about the people 72 involved in personal communications; it is used with STIR [RFC8224] 73 to convey a signed assertion of the identity of the participants in 74 real-time communications established via a protocol like SIP. This 75 specification extends PASSporT to include an indication that a call 76 has been diverted from its originally destination to a new one. 78 Although the STIR problem statement [RFC7340] is focused on 79 preventing the impersonation of the caller's identity, which is a 80 common enabler for threats such as robocalling and voicemail hacking 81 on the telephone network today, it also provides a signature over the 82 called number as the authentication service sees it. As [RFC8224] 83 Section 12.1 describes, this protection over the contents of the To 84 header field is intended to prevent a class of cut-and-paste attacks. 85 If Alice calls Bob, for example, Bob might attempt to cut-and-paste 86 the Identity header field in Alice's INVITE into a new INVITE that 87 Bob sends to Carol, and thus be able to fool Carol into thinking the 88 call came from Alice and not Bob. With the signature over the To 89 header field value, the INVITE Carol sees will clearly have been 90 destined originally for Bob, and thus Carol can view the INVITE as 91 suspect. 93 However, as [RFC8224] Section 12.1.1 points out, it is difficult for 94 Carol to confirm or reject these suspicions based on the information 95 she receives from the baseline PASSporT object. The common "call 96 forwarding" service serves as a good example of the fact that the 97 original called party number is not always the number to which a call 98 is delivered. The address in the To header field value of SIP 99 requests is not supposed to change, accordingly to baseline 100 [RFC3261], as it is the Request-URI that is supposed to be updated 101 when a call is retargeted, but practically speaking some operational 102 environments do alter the To header field. There are a number of 103 potential ways for intermediaries to indicate that such a forwarding 104 operating has taken place. The History-Info header field [RFC7044] 105 was created to store the Request-URIs that are discarded by a call in 106 transit. The SIP Diversion header field [RFC5806], though historic, 107 is still used for this purpose by some operators today. Neither of 108 these header fields provide any cryptographic assurance of secure 109 redirection, and they can both capture minor syntactical changes in 110 URIs that do not reflect a change to the actual target of a call. 112 This specification therefore extends PASSporT with an explicit 113 indication that original called number in PASSporT no longer reflects 114 the destination to which a call is likely to be delivered. 115 Verification services and the relying parties who make authorization 116 decisions about communications may use this indication to confirm 117 that a legitimate retargeting of the call has taken place, rather 118 than a cut-and-paste attack. 120 2. Terminology 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 125 described in [RFC2119]. 127 3. PASSporT 'div' Claim 129 This specification defines a new JSON Web Token claim for "div" which 130 indicates a previous destination for a call during its routing 131 process. When a retargeting entity receives a call signed with a 132 PASSporT, it may act as an authentication service and create a new 133 PASSporT containing the "div" claim to attach to the call (without 134 removing the original PASSporT). Note that a new PASSporT is only 135 necessary when the canonical form of the "dest" identifier (per the 136 canonicalization procedures in [RFC8224] Section 8) changes due to 137 this retargeting. "div" is typically populated with a destination 138 address found in the "dest" field of PASSporT received by the 139 retargeting entity, though it may include other elements as well, 140 including a copy of the original PASSporT. These new PASSporT 141 generated by retargeting entities MUST include the "div" PASSporT 142 type, and an "x5u" field pointing to a credential that the 143 retargeting entity controls. The new PASSporT header will look as 144 follows: 146 { "typ":"passport", 147 "ppt":"div", 148 "alg":"ES256", 149 "x5u":"https://www.example.com/cert.pkx" } 151 A PASSporT claims object containing "div" is populated with a 152 modification of the original token before the call was retargeted: at 153 a high level, the original identifier for the called party in the 154 "dest" array will become the "div" claim in the new PASSporT. If the 155 "dest" array of the original PASSporT contains multiple identifiers, 156 the retargeting entity MUST select only one them to occupy the "div" 157 field in the new PASSporT. and in particular, it MUST select an 158 identifier that is within the scope of the credential that the 159 retargeting entity will specify in the "x5u" of the PASSporT header 160 (as described below). 162 The new target for the call selected by the retargeting entity 163 becomes the value of the "dest" array of the new PASSporT. The 164 "orig" value MUST be copied into the new PASSporT from the original 165 PASSporT received by the retargeting entity. The retargeting entity 166 SHOULD retain the "iat" value from the original PASSporT, though if 167 in the underlying signaling protocol (e.g. SIP) the retargeting 168 entity changes the date and time information in the retargeted 169 request, the new PASSporT should instead reflect that date and time. 170 No other extension claims should be copied from the original PASSporT 171 to the "div" PASSporT. 173 So, for an original PASSporT of the form: 175 { "orig":{"tn":"12155551212"}, 176 "dest":{"tn":"12155551213"}, 177 "iat":1443208345 } 179 If the retargeting entity is changing the target from 12155551213 to 180 12155551214, the new PASSporT with "div" would look as follows: 182 { "orig":{"tn":"12155551212"}, 183 "dest":{"tn":"12155551214"}, 184 "iat":1443208345, 185 "div":{"tn":"121555551213"} } 187 Note that the "div" claim may contain other elements than just a 188 destination, including a copy of the original PASSporT (see 189 Section 3.1). After the PASSporT header and claims have been 190 constructed, their signature is generated per the guidance in 192 [RFC8225] - except for the credential required to sign it. While in 193 the ordinary construction of a PASSporT, the credential used to sign 194 will have authority over the identity in the "orig" claim (for 195 example, a certificate with authority over the telephone number in 196 "orig" per [RFC8226]), for all PASSporTs using the "div" type the 197 signature MUST be created with a credential with authority over the 198 identity present in the "div" claim. So for the example above, where 199 the original "dest" is "12155551213", the signer of the new PASSporT 200 object MUST have authority over that telephone number, and need not 201 have any authority over the telephone number present in the "orig" 202 claim. 204 3.1. Nesting the original PASSporT in 'div' 206 For some use cases, rather than having multiple unconnected PASSporTS 207 associated with a single call, it makes more sense to nest the 208 PASSporTs, explicitly relating two PASSporTs to one another. For 209 example, when storing a PASSporT with "div" at a Call Placement 210 Service (CPS) for STIR out-of-band [I-D.ietf-stir-oob] scenarios, 211 clients MUST include an "opt" element within "div". "opt" contains 212 the full form of the original PASSporT from which the "div" was 213 generated. If the diverting entity originally received that PASSporT 214 encrypted, it MUST decrypt it before storing it in "opt." The entire 215 "div" PASSporT would than be signed and re-encrypted normally for 216 storage at an out-of-band Call Placement Service (CPS). 218 A "div" PASSporT containing the "opt" would look as follows: 220 { "orig":{"tn":"12155551212"}, 221 "dest":{"tn":"12155551214"}, 222 "iat":1443208345, 223 "div":{"tn":"121555551213", 224 "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ 225 joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ 226 kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ 227 I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ 228 q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ 229 ojNCpTzO3QfPOlckGaS6hEck7w"} } 231 The "opt" extension is RECOMMENDED for use within in-band SIP use 232 cases as well. The alternative, having multiple Identity headers in 233 a SIP request, could be confusing for some verification services. 234 However, nested PASSporTs could result in lengthy Identity headers, 235 and some operational experience is needed to ascertain how viable 236 multiple layers of nesting will be. 238 4. Using 'div' in SIP 240 This section specifies SIP-specific usage for the "div" PASSporT type 241 and its handling in the SIP Identity header field "ppt" parameter 242 value. Other using protocols of PASSporT may define behavior 243 specific to their use of the "div" claim. 245 4.1. Authentication Service Behavior 247 An authentication service only adds an Identity header field 248 containing the "div" PASSporT type to an SIP request that already 249 contains at least one Identity header field; it MUST NOT add a "div" 250 request to an INVITE that contains no other Identity headers fields. 251 Note that the authentication service doing so does not remove or 252 replace any existing Identity header fields, it simply adds a new 253 one. When adding an Identity header field with a PASSporT object 254 containing a "div" claim, SIP authentication services MUST also add a 255 "ppt" parameter to that Identity header with a value of "div". The 256 resulting compact form Identity header field to add to the message 257 might look as follows: 259 Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 260 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 261 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 262 info=;alg=ES256;ppt="div" 264 A SIP authentication service typically will derive the new value of 265 "dest" from a new Request-URI that is set for the SIP request before 266 it is forwarded. Older values of the Request-URI may appear in 267 header fields like Diversion or History-Info; this document specifies 268 no specific interaction between the "div" mechanism and those SIP 269 header fields. Note as well that because PASSporT operates on 270 canonicalized telephone numbers and normalized URIs, many smaller 271 changes to the syntax of identifiers that might be captured by other 272 mechanisms (like History-Info) that record retargeting will likely 273 not require a "div" PASSporT. 275 4.2. Verification Service Behavior 277 [RFC8224] Section 6.2 Step 5 requires that specifications defining 278 "ppt" values describe any additional verifier behavior. The behavior 279 specified for the "div" value of "ppt" is as follows. 281 In order to use the "div" extension, a verification service needs to 282 inspect all of the valid Identity header field values associated with 283 a request, as an Identity header field value containing "div" 284 necessary refers to an earlier PASSporT already in the message. In 285 particular, the verification service must find a PASSporT associated 286 with the call, one created earlier, that contains a "dest" claim with 287 a value equivalent to the "div" claim in the current PASSporT. It is 288 possible that this earlier PASSporT will also contain a "div", and 289 that it will in turn chain to a still earlier PASSporT stored in a 290 different Identity header field value. Ultimately, by looking at 291 this chain of transformations and validating the associated 292 signatures, the verification service will be able to ascertain that 293 the appropriate parties were responsible for the retargeting of the 294 call to its ultimate destination; this can help the verification 295 service to determine that original PASSporT in the call was not 296 simply used in a cut-and-paste attack. This will help relying 297 parties to make any associated authorization decisions in terms of 298 how the call will be treated - though, per [RFC8224] Section 6.2.1, 299 that decision is a matter of local policy. 301 Note that Identity header fields are not ordered in a SIP request, 302 and in a case where there is a multiplicity of Identity header fields 303 in a request, some sorting may be required to match divert PASSporTs 304 to their originals. 306 5. 'div' and Redirection 308 The "div" mechanism exists primarily to prevent false negatives at 309 verification services when an arriving SIP request, due to 310 intermediary retargeting, does not appear to be intended for its 311 eventual recipient, because its "dest" value designates a different 312 original destination. Any intermediary that assigns a new target to 313 a request could choose to redirect with a 3xx response code instead 314 of retargeting. In ordinary operations, a redirection poses no 315 difficult for the operations of baseline STIR: when the UAC receives 316 the 3xx response, it will initiate a new request to the new target 317 (typically carried in the Contact header field value of the 3xx), and 318 the "dest" of the PASSporT created for the new request will match 319 that new target. As no impersonation attack can arise from this 320 case, it creates no new requirement for STIR. 322 However, some UACs record the original target of a call with 323 mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and 324 may want to leverage STIR to demonstrate to the ultimate recipient 325 that the call has been redirected securely: that is, that the 326 original destination was the one that sent the redirection message 327 that led to the recipient receiving the request. The semantics of 328 the PASSporT necessary to attest that are the same as those for the 329 "div" retargeting cases above. The only wrinkle is that the PASSporT 330 needs to be generated by the redirecting entity and sent back to the 331 originating user agent client within the 3xx response. 333 This introduces more complexity than might immediately be apparent. 334 In the first place, a 3xx response can convey multiple targets 335 through the Contact header field value; and thus the redirecting UAS 336 needs to include one nested PASSporT per new target. Bear in mind as 337 well that the original SIP request could have carried multiple 338 Identity header field values that had been added by different 339 authentication services in the request path. So a redirecting entity 340 might need to generate one nested "div" PASSporT per each PASSporT in 341 the original request per each Contact URI in the 3xx. Often that may 342 mean just one "div" PASSporT, but for some deployment scenarios, it 343 could require an impractical number of combinations. 345 STIR-aware intermediaries that redirect requests MAY therefore convey 346 one or more PASSporTs in the backwards direction within Identity 347 headers. This document consequently updates [RFC8224] to permit 348 carrying Identity headers in SIP 300-class responses. It is left to 349 authentication services to determine which Identity headers should be 350 copied into any new requests resulting from the redirection, if any: 351 use of these Identity headers by entities receiving a 3xx response is 352 OPTIONAL. 354 Finally, note that if an intermediary in the response path consumes 355 the 3xx and explores new targets itself while performing sequential 356 forking, it will effectively retarget the call on behalf of the 357 redirecting server, and this will create the same need for "div" 358 PASSporTs as any other retargeted call. 360 6. Extending 'div' to work with Service Logic Tracking 362 It is anticipated that "div" may be used in concert with History-Info 363 [RFC7044] in some deployments. It may not be clear from the "orig" 364 and "dest" values which History-Info header a given PASSporT 365 correlates to, especially because some of the target changes tracked 366 by History-Info will not be reflected in a "div" PASSporT (see 367 Section 1). Therefore an "hi" element may appear in "div" 368 corresponding to the History-Info header field index parameter value. 369 So for a History-Info header with an index value of "1.2.1", the 370 claims object of the corresponding PASSporT with "div" might look 371 like: 373 { "orig":{"tn":"12155551212"}, 374 "dest":{"tn":"12155551214"}, 375 "iat":1443208345, 376 "div":{"tn":"121555551213", 377 "hi":"1.2.1"} } 379 Past experience has shown that there may be additional information 380 about the motivation for retargeting that relying parties might 381 consider when making authorization decisions about a call, see for 382 example the "reason" associated with the SIP Diversion header field 383 [RFC5806]. Future extensions to this specification might incorporate 384 reasons into "div". 386 7. Acknowledgments 388 We would like to thank Robert Sparks for contributions to this 389 document. 391 8. IANA Considerations 393 This specification requests that the IANA add a new claim to the JSON 394 Web Token Claims registry as defined in [RFC7519]. 396 Claim Name: "div" 398 Claim Description: New Target of a Call 400 Change Controller: IESG 402 Specification Document(s): [RFCThis] 404 9. Security Considerations 406 This specification describes a security feature, and is primarily 407 concerned with increasing security when calls are forwarded. 408 Including information about how calls were retargeted during the 409 routing process can allow downstream entities to infer particulars of 410 the policies used to route calls through the network. However, 411 including this information about forwarding is at the discretion of 412 the retargeting entity, so if there is a requirement to keep the 413 original called number confidential, no PASSporT should be created 414 for that retargeting - the only consequence will be that downstream 415 entities will be unable to correlate an incoming call with the 416 original PASSporT without access to some prior knowledge of the 417 policies that could have caused the retargeting. 419 10. Informative References 421 [I-D.ietf-stir-oob] 422 Rescorla, E. and J. Peterson, "STIR Out-of-Band 423 Architecture and Use Cases", draft-ietf-stir-oob-01 (work 424 in progress), October 2017. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 432 A., Peterson, J., Sparks, R., Handley, M., and E. 433 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 434 DOI 10.17487/RFC3261, June 2002, 435 . 437 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 438 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 439 . 441 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 442 C. Holmberg, "An Extension to the Session Initiation 443 Protocol (SIP) for Request History Information", RFC 7044, 444 DOI 10.17487/RFC7044, February 2014, 445 . 447 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 448 Telephone Identity Problem Statement and Requirements", 449 RFC 7340, DOI 10.17487/RFC7340, September 2014, 450 . 452 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 453 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 454 . 456 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 457 "Authenticated Identity Management in the Session 458 Initiation Protocol (SIP)", RFC 8224, 459 DOI 10.17487/RFC8224, February 2018, 460 . 462 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 463 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 464 . 466 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 467 Credentials: Certificates", RFC 8226, 468 DOI 10.17487/RFC8226, February 2018, 469 . 471 Author's Address 473 Jon Peterson 474 Neustar, Inc. 475 1800 Sutter St Suite 570 476 Concord, CA 94520 477 US 479 Email: jon.peterson@neustar.biz