idnits 2.17.1 draft-ietf-stir-passport-divert-09.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 are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCThis' is mentioned on line 726, but not defined Summary: 1 error (**), 0 flaws (~~), 3 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 Updates: RFC8224 (if approved) July 13, 2020 5 Intended status: Standards Track 6 Expires: January 14, 2021 8 PASSporT Extension for Diverted Calls 9 draft-ietf-stir-passport-divert-09 11 Abstract 13 PASSporT is specified in RFC 8225 to convey cryptographically-signed 14 information about the people involved in personal communications. 15 This document extends PASSporT to include an indication that a call 16 has been diverted from its original destination to a new one. This 17 information can greatly improve the decisions made by verification 18 services in call forwarding scenarios. Also specified here is an 19 encapsulation mechanism for nesting a PASSporT within another 20 PASSporT that assists relying parties in some diversion scenarios. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 14, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4 59 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 61 4.2. Verification Service Behavior . . . . . . . . . . . . . . 8 62 5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10 63 5.1. Processing 'div-o' PASSporTs . . . . . . . . . . . . . . 12 64 6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 13 65 7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 13 66 8. Extending 'div' to work with Service Logic Tracking . . . . . 14 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 10.1. JSON Web Token Claims Registrations . . . . . . . . . . 15 70 10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 15 71 10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 16 72 10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 16 73 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 74 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 77 13.2. Informative References . . . . . . . . . . . . . . . . . 18 78 Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 19 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 A Personal Assertion Token (PASSporT [RFC8225]) is a token format 84 based on the JSON Web Token (JWT [RFC7519]) for conveying 85 cryptographically-signed information about the people involved in 86 personal communications; it is used by the Secure Telephone Identity 87 Revisited (STIR [RFC8224]) protocol to convey a signed assertion of 88 the identity of the participants in real-time communications 89 established via a protocol like SIP. This specification extends 90 PASSporT to include an indication that a call has been diverted from 91 its original destination to a new one. 93 Although the STIR problem statement [RFC7340] is focused on 94 preventing the impersonation of the caller's identity, which is a 95 common enabler for threats such as robocalling and voicemail hacking 96 on the telephone network today, it also provides a signature over the 97 called number at the time that the authentication service sees it. 98 As [RFC8224] Section 12.1 describes, this protection over the 99 contents of the To header field is intended to prevent a class of 100 cut-and-paste attacks. If Alice calls Bob, for example, Bob might 101 attempt to cut-and-paste the Identity header field in Alice's INVITE 102 into a new INVITE that Bob sends to Carol, and thus be able to fool 103 Carol into thinking the call came from Alice and not Bob. With the 104 signature over the To header field value, the INVITE Carol sees will 105 clearly have been destined originally for Bob, and thus Carol can 106 view the INVITE as suspect. 108 However, as [RFC8224] Section 12.1.1 points out, it is difficult for 109 Carol to confirm or reject these suspicions based on the information 110 she receives from the baseline PASSporT object. The common "call 111 forwarding" service serves as a good example of the reality that the 112 original called party number is not always the number to which a call 113 is delivered. There are a number of potential ways for 114 intermediaries to indicate that such a forwarding operating has taken 115 place. The address in the To header field value of SIP requests is 116 not supposed to change, according to baseline SIP behavior [RFC3261]; 117 instead, it is the Request-URI that is supposed to be updated when a 118 call is retargeted. Practically speaking, however, many operational 119 environments do alter the To header field. The History-Info header 120 field [RFC7044] was created to store the Request-URIs that are 121 discarded by a call in transit. The SIP Diversion header field 122 [RFC5806], though historic, is still used for this purpose by some 123 operators today. Neither of these header fields provide any 124 cryptographic assurance of secure redirection, and they both record 125 entries for minor syntactical changes in URIs that do not reflect a 126 change to the actual target of a call. 128 This specification therefore extends PASSporT with an explicit 129 indication that the original called number in PASSporT no longer 130 reflects the destination to which a call is intended to be delivered. 131 For this purpose, it specifies a Divert PASSporT type ("div") for use 132 in common SIP retargeting cases; it is expected that in this case, 133 SIP INVITE requests will carry multiple Identity header fields, each 134 containing its own PASSporT. Throughout this document, PASSporTs 135 that contain a "div" element will be referred to as "div" PASSporTs. 136 Verification services and the relying parties who make authorization 137 decisions about communications may use this diversion indication to 138 confirm that a legitimate retargeting of the call has taken place, 139 rather than a cut-and-paste attack. For out-of-band 140 [I-D.ietf-stir-oob] use cases, and other non-SIP applications of 141 PASSporT, a separate "div-o" PASSporT type is also specified, which 142 defines an "opt" PASSporT element for carrying nested PASSporTs 143 within a PASSporT. These shall in turn be referred to in this 144 document as "div-o" PASSporTs. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 3. The 'div' PASSporT Type and Claim 156 This specification defines a PASSporT [RFC8225] type called "div" 157 that may be employed by authentication services located at 158 retargeting entities. All "div" PASSporTs MUST contain a new JSON 159 Web Token "div" claim, also specified in this document, which 160 indicates a previous destination for a call during its routing 161 process. When a retargeting entity receives a call signed with a 162 PASSporT, it may act as an authentication service and create a new 163 PASSporT containing the "div" claim to attach to the call. 165 Note that a new PASSporT is only necessary when the canonical form of 166 the "dest" identifier (per the canonicalization procedures in 167 [RFC8224] Section 8.3) changes due to this retargeting. If the 168 canonical form of the "dest" identifier is not changed during 169 retargeting, then a new PASSporT with a "div" claim MUST NOT be 170 produced. 172 The headers of the new PASSporTs generated by retargeting entities 173 MUST include the "div" PASSporT type, and an "x5u" field pointing to 174 a credential that the retargeting entity controls. "div" PASSporTs 175 MUST use full form instead of compact form. The new PASSporT header 176 will look as follows: 178 { "typ":"passport", 179 "ppt":"div", 180 "alg":"ES256", 181 "x5u":"https://www.example.com/cert.cer" } 183 A "div" PASSporT claims set is populated with elements drawn from the 184 PASSporT(s) received for a call by the retargeting entity: at a high 185 level, the original identifier for the called party in the "dest" 186 object will become the "div" claim in the new PASSporT. If the 187 "dest" object of the original PASSporT contains multiple identifiers, 188 because it contains one or more name/value pairs with an array as its 189 value, the retargeting entity MUST select only one identifier from 190 the value(s) of the "dest" object to occupy the value of the "div" 191 field in the new PASSporT. Moreover, it MUST select an identifier 192 that is within the scope of the credential that the retargeting 193 entity will specify in the "x5u" of the PASSporT header (as described 194 below). 196 The new target for the call selected by the retargeting entity 197 becomes the value of the "dest" object of the new PASSporT. The 198 "orig" object MUST be copied into the new PASSporT from the original 199 PASSporT received by the retargeting entity. The retargeting entity 200 SHOULD retain the "iat" object from the original PASSporT, though if 201 in the underlying signaling protocol (e.g. SIP) the retargeting 202 entity changes the date and time information in the retargeted 203 request, the new PASSporT should instead reflect that date and time. 204 No other claims or extensions are to be copied from the original 205 PASSporT to the "div" PASSporT. 207 So, for an original PASSporT claims set of the form: 209 { "dest":{"tn":["12155551213"]}, 210 "iat":1443208345, 211 "orig":{"tn":"12155551212"} } 213 If the retargeting entity is changing the target from 12155551213 to 214 12155551214, the claims set of a "div" PASSpoRT generated by the 215 retargeting entity would look as follows: 217 { "dest":{"tn":["12155551214"]}, 218 "div":{"tn":"121555551213"}, 219 "iat":1443208345, 220 "orig":{"tn":"12155551212"} } 222 The combined full form PASSporT (with a signature covered by the 223 ES256 keys given in Appendix A) would look as follows: 225 eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ 226 oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ 227 jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ 228 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ 229 J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ 230 SqIlk3yCNkg 232 The same "div" PASSporT would result if the "dest" object of the 233 original PASSporT contained an array value, such as 234 {"tn":["12155551213","19995551234"]}, and the retargeting entity 235 chose to retarget from the first telephone number in the array. 236 Every "div" PASSporT is diverting from only one identifier. 238 Note that the "div" element may contain other name/value pairs than 239 just a destination, including a History-Info indicator (see 240 Section 8). After the PASSporT header and claims have been 241 constructed, their signature is generated per the guidance in 242 [RFC8225] - except for the credential required to sign it. While in 243 the ordinary construction of a PASSporT, the credential used to sign 244 will have authority over the identity in the "orig" claim (for 245 example, a certificate with authority over the telephone number in 246 "orig" per [RFC8226]), for all PASSporTs using the "div" type the 247 signature MUST be created with a credential with authority over the 248 identity present in the "div" claim. So for the example above, where 249 the original "dest" is "12155551213", the signer of the new PASSporT 250 object MUST have authority over that telephone number, and need not 251 have any authority over the telephone number present in the "orig" 252 claim. 254 Note that Identity header fields are not ordered in a SIP request, 255 and in a case where there is a multiplicity of Identity header fields 256 in a request, some sorting may be required to match "div" PASSporTs 257 to their originals. 259 PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6) 260 element in their payload. 262 4. Using 'div' in SIP 264 This section specifies SIP-specific usage for the "div" PASSporT type 265 and its handling in the SIP Identity header field "ppt" parameter 266 value. Other protocols using PASSporT may define behavior specific 267 to their use of the "div" claim. 269 4.1. Authentication Service Behavior 271 An authentication service only adds an Identity header field value 272 containing the "div" PASSporT type to a SIP request that already 273 contains at least one Identity header field value; it MUST NOT add a 274 "div" PASSporT to an INVITE that contains no Identity header field. 275 The retargeting entity SHOULD act as a verification service and 276 validate the existing Identity header field value(s) in the request 277 before proceeding; in some high-volume environments, it may instead 278 put that burden of validating the chain entirely on the terminating 279 verification service. As the authentication service will be adding a 280 new PASSporT that refers to an original, it MUST NOT remove the 281 original request's Identity header field value before forwarding. 283 As was stated in Section 3, the authentication service MUST sign any 284 "div" PASSporT with a credential that has a scope of authority 285 covering the identity it populates in the "div" element value. Note 286 that this is a significant departure from baseline STIR 287 authentication service behavior, in which the PASSporT is signed by a 288 credential with authority over the "orig" field. The "div" value 289 reflects the URI that caused the call to be routed to the retargeting 290 entity, so in ordinary operations, it would already be the STIR 291 entity holding the appropriate private keying material for calls 292 originating from that identity. 294 A SIP authentication service typically will derive the "dest" element 295 value of a "div" PASSporT from a new Request-URI that is set for the 296 SIP request before it is forwarded. Older values of the Request-URI 297 may appear in header fields like Diversion or History-Info; this 298 document specifies an optional interaction with History-Info below in 299 Section 8. Note as well that because PASSporT operates on 300 canonicalized telephone numbers and normalized URIs, many smaller 301 changes to the syntax of identifiers that might be captured by other 302 mechanisms that record retargeting (like History-Info) will likely 303 not require a "div" PASSporT. 305 When adding an Identity header field with a PASSporT claims set 306 containing a "div" claim, SIP authentication services MUST also add a 307 "ppt" parameter to that Identity header with a value of "div". For 308 the example PASSporT given in Section 3, the new Identity header 309 added after retargeting might look as follows: 311 Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \ 312 iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \ 313 Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \ 314 MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \ 315 xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \ 316 ChHhVIiMTSqIlk3yCNkg; \ 317 info=;ppt="div" 319 Note that in some deployments, an authentication service will need to 320 generate "div" PASSporTs for a request that contains multiple 321 non-"div" Identity header field values. For example, a request 322 arriving at a retargeting entity might contain in different Identity 323 header fields a baseline [RFC8224] PASSporT and a PASSporT of type 324 "rph" [RFC8443] signed by a separate authority. Provided that these 325 PASSporTs share the same "orig" and "dest" values, the retargeting 326 entity's authentication service SHOULD generate only one "div" 327 PASSporT. If the "orig" or "dest" of these PASSporTs differ, 328 however, one "div" PASSporT SHOULD be generated for each non-"div" 329 PASSporT. Note that this effectively creates multiple chains of 330 "div" PASSporTs in a single request, which complicates the procedures 331 that need to be performed at verification services. 333 Furthermore, a request may also be retargeted a second time, at which 334 point the subsequent retargeting entity SHOULD generate one "div" 335 PASSporT for each previous "div" PASSporT in the request which 336 contains a "dest" object with the value of the current target - but 337 not for "div" PASSporTs with earlier targets. Ordinarily, the 338 current target will be readily identifiable, as it will be in the 339 last "div" PASSporT in each chain, and in SIP cases it will 340 correspond to the Request-URI received by the retargeting entity. 341 Moreover, the current target will be an identifier that the 342 retargeting entity possesses a credential to sign for, which may not 343 be true for earlier targets. Ultimately, on each retargeting, the 344 number of PASSporTs added to a request will be equal to the number of 345 non-"div" PASSporTs that do not share the same "orig" and "dest" 346 object values. 348 4.2. Verification Service Behavior 350 [RFC8224] Section 6.2 Step 5 requires that specifications defining 351 "ppt" values describe any additional or alternative verifier 352 behavior. The job of a SIP verification service handling one or more 353 "div" PASSporTs is very different from that of a traditional 354 verification service. At a high level, the immediate responsibility 355 of the verification service is to extract all PASSporTs from the two 356 or more Identity header fields in a request, identify which are "div" 357 PASSporTs and which are not, and then order and link the "div" 358 PASSporTs to the original PASSporT(s) in order to build one or more 359 chains of retargeting. 361 In order to validate a SIP request using the "div" PASSporT type, a 362 verification service needs to inspect all of the valid Identity 363 header field values associated with a request, as an Identity header 364 field value containing "div" necessarily refers to an earlier 365 PASSporT already in the message. For each "div" PASSporT, the 366 verification service MUST find an earlier PASSporT that contains a 367 "dest" claim with a value equivalent to the "div" claim in each "div" 368 PASSporT. It is possible that this earlier PASSporT will also 369 contain a "div", and that it will in turn chain to a still earlier 370 PASSporT stored in a different Identity header field value. If a 371 complete chain cannot be constructed, the verification service cannot 372 complete "div" validation; it MAY still validate any non-"div" 373 PASSporTs in the request per normal [RFC8224] procedures. If a chain 374 has been successfully constructed, the verification service extracts 375 from the outermost (that is, the most recent) PASSporT in the chain a 376 "dest" field; this will be a "div" PASSporT that no other "div" 377 PASSporT in the SIP request refers to. Its "dest" element value will 378 be referred to in the procedures that follow as the value of the 379 "outermost "dest" field." 381 Ultimately, by looking at this chain of transformations and 382 validating the associated signatures, the verification service will 383 be able to ascertain that the appropriate parties were responsible 384 for the retargeting of the call to its current destination. This can 385 help the verification service to determine that the original PASSporT 386 in the call was not simply used in a cut-and-paste attack and inform 387 any associated authorization decisions in terms of how the call will 388 be treated - though, per [RFC8224] Section 6.2.1, that decision is a 389 matter of local policy and is thus outside the scope of this 390 specification. 392 A verification service parses a chain of PASSporTs as follows: 394 First, the verification service MUST compare the value in the 395 outermost "dest" field to the target of the call. As it is 396 anticipated that SIP authentication services that create "div" 397 PASSporTs will populate the "dest" header from the retargeted 398 Request-URI (see Section 4.1), in ordinary SIP operations, the 399 Request-URI is where verification services will find the latest 400 call target. Note however that after a "div" PASSporT has been 401 added to a SIP request, the Request-URI may have been updated 402 during normal call processing to an identifier that no longer 403 contains the logical destination of a call; in this case, the 404 verification service MAY compare the "dest" field to a provisioned 405 telephone number for the recipient. 407 Second, the verification service MUST validate the signature over 408 the outermost "div" PASSporT, and establish that the credential 409 that signed the "div" PASSporT has the authority to attest for the 410 identifier in the "div" element of the PASSporT (per [RFC8224] 411 Section 6.2 Step 3). 413 Third, the verification service MUST validate that the "orig" 414 field of the innermost PASSporT of the chain (the only PASSporT in 415 the chain which will not be of PASSporT type "div") is equivalent 416 to the "orig" field of the outermost "div" PASSporT; in other 417 words, that the original calling identifier has not been altered 418 by retargeting authentication services. If the "orig" value has 419 changed, the verification service MUST treat the entire PASSporT 420 chain as invalid. The verification service MUST also verify that 421 all other "div" PASSporTs in the chain share the same "orig" 422 value. Then the verification service validates the relationship 423 of the "orig" field to the SIP-level call signaling per the 424 guidance in [RFC8224] Section 6.2 Step 2. 426 Fourth, the verification service MUST check the date freshness in 427 the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It 428 is furthermore RECOMMENDED that the verification service check 429 that the "iat" field of the innermost PASSporT is also within the 430 date freshness interval; otherwise the verification service could 431 allow attackers to replay an old, stale PASSporT embedded in a 432 fresh "div". However, note that in some use cases, including 433 certain ways that call transfers are implemented, it is possible 434 that an established call will be retargeted long after it has 435 originally been placed, and verification services may want to 436 allow a longer window for the freshness of the innermost PASSporT 437 if the call is transferred from a trusted party (as an upper 438 bound, a freshness window on the order of three hours might 439 suffice). 441 Fifth, the verification service MUST inspect and validate the 442 signatures on each and every PASSporT object in the chain between 443 the outermost "div" PASSporT and the innermost PASSporT. Note 444 that (per Section 4.1) a chain may terminate at more than one 445 innermost PASSporT, in cases where a single "div" is used to 446 retarget from multiple innermost PASSporTs. Also note that 447 [RFC8224] Section 6.2 Step 1 applies to the chain validation 448 process: if the innermost PASSporT contains an unsupported "ppt", 449 its chain MUST be ignored. 451 Note that the To header field is not used in the first step above. 452 Optionally, the verification service MAY verify that the To header 453 field value of the received SIP signaling is equal to the "dest" 454 value in the innermost PASSporT; however, as has been observed in 455 some deployments, the original To header field value may be altered 456 by intermediaries to reflect changes of target. Deployments that 457 change the original To header field value to conceal the original 458 destination of the call from the ultimate recipient should note that 459 the original destination of a call may be preserved in the innermost 460 PASSporT. Future work on "div" might explore methods to implement 461 that sort of policy while retaining a secure chain of redirection. 463 5. The 'div-o' PASSporT Type 465 This specification defines a "div-o" PASSporT type that uses the 466 "div" claim element in conjunction with the "opt" (Section 6) claim 467 element. As is the case with "div" PASSporT type, a "div-o" PASSporT 468 is created by an authentication service acting for a retargeting 469 entity, but instead of generating a separate "div" PASSporT to be 470 conveyed alongside an original PASSporT, the authentication service 471 in this case embeds the original PASSporT inside the "opt" element of 472 the "div-o" PASSporT. The "div-o" extension is designed for use in 473 non-SIP or gatewayed SIP environments where the conveyance of 474 PASSporTs in separate Identity header fields in impossible, such as 475 out-of-band [I-D.ietf-stir-oob] STIR scenarios. 477 The syntax of "div-o" PASSporTs is very similar to "div". A "div-o" 478 PASSporT header object might look as follows: 480 { "typ":"passport", 481 "ppt":"div-o", 482 "alg":"ES256", 483 "x5u":"https://www.example.com/cert.cer" } 485 Whereas a "div" PASSporT claims set contains only the "orig", "dest", 486 "iat", and "div" elements, the "div-o" additionally MUST contain an 487 "opt" element (see Section 6), which encapsulates the full form of 488 the previous PASSporT from which the call was retargeted, triggering 489 the generation of this "div-o". The format of the "opt" element is 490 identical to the encoded PASSporT format given in Appendix A of 491 [RFC8225]. 493 So, for an original PASSporT claims set of the form: 495 { "orig":{"tn":"12155551212"}, 496 "dest":{"tn":["12155551213"]}, 497 "iat":1443208345 } 499 If the retargeting entity is changing the target from 12155551213 to 500 12155551214, the new PASSporT claims set for "div-o" would look as 501 follows: 503 { "orig":{"tn":"12155551212"}, 504 "dest":{"tn":["12155551214"]}, 505 "iat":1443208345, 506 "div":{"tn":"121555551213"}, 507 "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \ 508 HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \ 509 EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \ 510 E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \ 511 RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" } 513 While in ordinary operations, it is not expected that SIP would carry 514 a "div-o" PASSporT, it might be possible in some gatewaying 515 scenarios. The resulting full form Identity header field with a 516 "div-o" PASSporT would look as follows: 518 Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \ 519 nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \ 520 N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \ 521 In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \ 522 I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \ 523 YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \ 524 V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \ 525 T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \ 526 BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \ 527 VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \ 528 HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \ 529 LaDV2y2VtHTLIEgmHig; \ 530 info=;ppt="div-o" 532 5.1. Processing 'div-o' PASSporTs 534 The authentication and verification service procedures required for 535 "div-o" closely follow the guidance given in Section 4.1 and 536 Section 4.2, with the major caveats being first, that they do store 537 or retrieve PASSporTs via the Identity header field values of SIP 538 requests, and second, that they process nested PASSporTs in the "opt" 539 claim element. But transposing the rest of the behaviors described 540 above to creating and validating "div-o" PASSporTs is 541 straightforward. 543 For the "div-o" PASSporT type, retargeting authentication services 544 that handle calls with one or more existing PASSporTs will create a 545 corresponding "div-o" PASSporT for each received PASSporT. Each 546 "div-o" PASSporT MUST contain an "opt" claim set element with the 547 value of the original PASSporT from which the "div-o" was created; 548 and as specified in Section 4.1, the authentication service MUST 549 populate the "div" claim set element of the "div-o" PASSporT with the 550 "dest" field fo the original PASSporT. Each received PASSporT may in 551 turn contain its own "opt" claim set element, if the retargeting 552 authentication service is not the first in its chain. Note that if 553 the retargeting authentication service is handling a call with 554 multiple PASSporTs, which in ordinary SIP operation would result in 555 the construction of multiple "div" chains, it will in effect be 556 generating one "div-o" PASSporT per chain. 558 The job of a verification service is in many ways easier for "div-o" 559 than for "div", as the verification service has no need to correlate 560 the PASSporTs it receives and assemble them into chains, as any 561 chains in "div-o" will be nested through the "opt" element. 562 Nonetheless, the verification services MUST perform the same chain 563 validation described in Section 4.2 to validate that each nested 564 PASSporT shares the same "orig" field as its enclosing PASSporT, and 565 that the "dest" field of each nested PASSporT corresponds to the 566 "div" field of its enclosing PASSporT. The same checks MUST also be 567 performed for freshness, signature validation, and so on. It is 568 similarly OPTIONAL for the verification service to determine that the 569 "dest" claims element of the outermost PASSporT corresponds to the 570 called party indication of receive telephone signaling, where such 571 indication would vary depending on the using protocol. 573 How authentication services or verification services receive or 574 transport PASSporTs for "div-o" is outside the scope of this 575 document, and dependent on the using protocol. 577 6. Definition of 'opt' 579 The presence of an "Original PASSporT" ("opt") claims set element 580 signifies that a PASSporT encapsulates another entire PASSporT within 581 it, typically a PASSporT that was transformed in some way to create 582 the current PASSporT. Relying parties may need to consult the 583 encapsulated PASSporT in order to validate the identity of a caller. 584 "opt" as defined in this specification may be used by future PASSporT 585 extensions as well as in conjunction with "div-o". 587 "opt" MUST contain a quoted full-form PASSporT as specified by 588 [RFC8225] Appendix A; it MUST NOT contain a compact form PASSporT. 589 For an example of a "div-o" PASSporT containing "opt," see Section 5. 591 7. 'div' and Redirection 593 The "div" mechanism exists primarily to prevent false negatives at 594 verification services when an arriving SIP request, due to 595 intermediary retargeting, does not appear to be intended for its 596 eventual recipient, because the original PASSporT "dest" value 597 designates a different destination. 599 Any intermediary that assigns a new target to a request can, instead 600 of retargeting and forwarding the request, instead redirect with a 601 3xx response code. In ordinary operations, a redirection poses no 602 difficulties for the operations of baseline STIR: when the user agent 603 client (UAC) receives the 3xx response, it will initiate a new 604 request to the new target (typically the target carried in the 605 Contact header field value of the 3xx), and the "dest" of the 606 PASSporT created for the new request will match that new target. As 607 no impersonation attack can arise from this case, it creates no new 608 requirements for STIR. 610 However, some UACs record the original target of a call with 611 mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and 612 may want to leverage STIR to demonstrate to the ultimate recipient 613 that the call has been redirected securely: that is, that the 614 original destination was the one that sent the redirection message 615 that led to the recipient receiving the request. The semantics of 616 the PASSporT necessary for that assertion are the same as those for 617 the "div" retargeting cases above. The only wrinkle is that the 618 PASSporT needs to be generated by the redirecting entity and sent 619 back to the originating user agent client within the 3xx response. 621 This introduces more complexity than might immediately be apparent. 622 In the first place, a 3xx response can convey multiple targets 623 through the Contact header field value; to accommodate this, the 624 "div" PASSporT MAY include one "dest" object array value per Contact, 625 but if the retargeting entity wants to keep the Contact list private 626 from targets, it may need to generate one PASSporT per Contact. Bear 627 in mind as well that the original SIP request could have carried 628 multiple Identity header field values that had been added by 629 different authentication services in the request path, so a 630 redirecting entity might need to generate one "div" PASSporT for each 631 PASSporT in the original request. Often, this will mean just one 632 "div" PASSporT, but for some deployment scenarios, it could require 633 an impractical number of combinations. But in very complex call 634 routing scenarios, attestation of source identity would only add 635 limited value anyway. 637 STIR-aware SIP intermediaries that redirect requests MAY therefore 638 convey one or more PASSporTs in the backwards direction within 639 Identity header fields. These redirecting entities will act as 640 authentication services for "div" as described in Section 4.1. This 641 document consequently updates [RFC8224] to permit carrying Identity 642 header fields in SIP 300-class responses. It is left to the 643 originating user agent to determine which Identity header fields 644 should be copied from the 3xx into any new requests resulting from 645 the redirection, if any: use of these Identity header fields by 646 entities receiving a 3xx response is OPTIONAL. 648 Finally, note that if an intermediary in the response path consumes 649 the 3xx and explores new targets itself while performing sequential 650 forking, it will effectively retarget the call on behalf of the 651 redirecting server, and this will create the same need for "div" 652 PASSporTs as any other retargeted call. These intermediaries MAY 653 also copy PASSporTs from the 3xx response and insert them into 654 sequential forking requests, if appropriate. 656 8. Extending 'div' to work with Service Logic Tracking 658 It is anticipated that "div" may be used in concert with History-Info 659 [RFC7044] in some deployments. It may not be clear from the "orig" 660 and "dest" values which History-Info header a given PASSporT 661 correlates to, especially because some of the target changes tracked 662 by History-Info will not be reflected in a "div" PASSporT (see 663 Section 1). Therefore an "hi" element as defined here may appear in 664 "div" corresponding to the History-Info header field index parameter 665 value. So for a History-Info header field with an index value of 666 "1.2.1", the claims set of the corresponding PASSporT with "div" 667 might look like: 669 { "orig":{"tn":"12155551212"}, 670 "dest":{"tn":["12155551214"]}, 671 "iat":1443208345, 672 "div":{"tn":"121555551213", 673 "hi":"1.2.1"} } 675 Past experience has shown that there may be additional information 676 about the motivation for retargeting that relying parties might 677 consider when making authorization decisions about a call, see for 678 example the "reason" associated with the SIP Diversion header field 679 [RFC5806]. Future extensions to this specification might incorporate 680 reasons into "div". 682 9. Acknowledgments 684 We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean 685 Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks 686 for contributions to this document. 688 10. IANA Considerations 690 This document contains actions for the IANA. 692 10.1. JSON Web Token Claims Registrations 694 This specification requests that the IANA add two new claims to the 695 JSON Web Token Claims registry as defined in [RFC7519]. 697 10.1.1. 'div' registration 699 Claim Name: "div" 701 Claim Description: Diverted Target of a Call 703 Change Controller: IESG 705 Specification Document(s): [RFCThis] 707 10.1.2. 'opt' registration 709 Claim Name: "opt" 711 Claim Description: Original PASSporT (in Full Form) 713 Change Controller: IESG 715 Specification Document(s): [RFCThis] 717 10.2. PASSporT Type Registrations 719 This specification defines two new PASSporT types for the PASSport 720 Extensions Registry defined in [RFC8225], which resides at 721 https://www.iana.org/assignments/passport/passport.xhtml#passport- 722 extensions. They are: 724 "div" as defined in [RFCThis] Section 3. 726 "div-o" as defined in [RFCThis] Section 5. 728 11. Privacy Considerations 730 There is an inherent trade-off in any mechanism that tracks in SIP 731 signaling how calls are routed through a network, as routing 732 decisions may expose policies set by users for how calls are 733 forwarded, potentially revealing relationships between different 734 identifiers representing the same user. Note however that in 735 ordinary operations, this information is revealed to the user agent 736 service of the called party, not the calling party. It is usually 737 the called party who establishes these forwarding relationships, and 738 if indeed some other party is responsible for calls being forwarded 739 to the called party, many times the called party should likely be 740 entitled to information about why they are receiving these calls. 741 Similarly, a redirecting entity who sends a 3xx in the backwards 742 direction knowingly shares information about service logic with the 743 caller's network. However, as there may be unforeseen circumstances 744 where the revelation of service logic to the called party poses a 745 privacy risk, implementers and users of this or similar diversion- 746 tracking techniques should understand the trade-off. 748 Furthermore, it is a general privacy risk of identity mechanisms 749 overall that they do not interface well with anonymization services; 750 the interaction of STIR with anonymization services is detailed in 751 [RFC8224] Section 11. Any forwarding service that acts as an 752 anonymizing proxy may not be able to provide a secure chain of 753 retargeting due to the obfuscation of the originating identity. 755 Also see [RFC8224] Section 11 for further considerations on the 756 privacy of using PASSporTs in SIP. 758 12. Security Considerations 760 This specification describes a security feature, and is primarily 761 concerned with increasing security when calls are forwarded. 762 Including information about how calls were retargeted during the 763 routing process can allow downstream entities to infer particulars of 764 the policies used to route calls through the network. However, 765 including this information about forwarding is at the discretion of 766 the retargeting entity, so if there is a requirement to keep an 767 intermediate called number confidential, no PASSporT should be 768 created for that retargeting - the only consequence will be that 769 downstream entities will be unable to correlate an incoming call with 770 the original PASSporT without access to some prior knowledge of the 771 policies that could have caused the retargeting. 773 Any extension that makes PASSporTs larger creates a potential 774 amplification mechanism for SIP-based DDoS attacks. Since diversion 775 PASSporTs are created as a part of normal forwarding activity, this 776 risk arises at the discretion of the retargeting domain: simply using 777 3xx response redirections rather than retargeting (by supplying a 778 "div" per Section 7) mitigates the potential impact. Under unusual 779 traffic loads, even domains that might ordinarily retarget requests 780 can switch to redirection. 782 SIP has an inherent capability to redirect requests, including 783 forking them to multiple parties -- potentially a very large numbers 784 of parties. The use of the "div" PASSporT type does not grant any 785 additional powers to attackers who hope to place bulk calls; if 786 present, the "div" PASSporT instead identifies the party responsible 787 for the forwarding. As such, senders of bulk unsolicited traffic are 788 unlikely to find the use of "div" attractive. 790 13. References 792 13.1. Normative References 794 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 795 Requirement Levels", BCP 14, RFC 2119, 796 DOI 10.17487/RFC2119, March 1997, 797 . 799 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 800 A., Peterson, J., Sparks, R., Handley, M., and E. 801 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 802 DOI 10.17487/RFC3261, June 2002, 803 . 805 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 806 C. Holmberg, "An Extension to the Session Initiation 807 Protocol (SIP) for Request History Information", RFC 7044, 808 DOI 10.17487/RFC7044, February 2014, 809 . 811 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 812 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 813 . 815 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 816 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 817 May 2017, . 819 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 820 "Authenticated Identity Management in the Session 821 Initiation Protocol (SIP)", RFC 8224, 822 DOI 10.17487/RFC8224, February 2018, 823 . 825 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 826 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 827 . 829 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 830 Credentials: Certificates", RFC 8226, 831 DOI 10.17487/RFC8226, February 2018, 832 . 834 13.2. Informative References 836 [I-D.ietf-stir-oob] 837 Rescorla, E. and J. Peterson, "STIR Out-of-Band 838 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 839 in progress), March 2020. 841 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 842 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 843 . 845 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 846 Telephone Identity Problem Statement and Requirements", 847 RFC 7340, DOI 10.17487/RFC7340, September 2014, 848 . 850 [RFC8443] Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal 851 Assertion Token (PASSporT) Extension for Resource Priority 852 Authorization", RFC 8443, DOI 10.17487/RFC8443, August 853 2018, . 855 Appendix A. Appendix A: Keys for Examples 857 The following EC256 keys are used in the signing examples given in 858 this document. WARNING: Do not use this key pair in production 859 systems. 861 -----BEGIN PUBLIC KEY----- 862 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4 863 hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== 864 -----END PUBLIC KEY----- 866 -----BEGIN EC PRIVATE KEY----- 867 MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49 868 AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4 869 +Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== 870 -----END EC PRIVATE KEY----- 872 Author's Address 874 Jon Peterson 875 Neustar, Inc. 876 1800 Sutter St Suite 570 877 Concord, CA 94520 878 US 880 Email: jon.peterson@team.neustar