idnits 2.17.1 draft-ietf-sipcore-rejected-05.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 31, 2019) is 1824 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: 'RFCXXXX' is mentioned on line 787, but not defined -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE E. Burger 3 Internet-Draft Georgetown University 4 Intended status: Standards Track B. Nagda 5 Expires: October 2, 2019 Massachusetts Institute of Technology 6 March 31, 2019 8 A Session Initiation Protocol (SIP) Response Code for Rejected Calls 9 draft-ietf-sipcore-rejected-05 11 Abstract 13 This document defines the 608 (Rejected) SIP response code. This 14 response code enables calling parties to learn that an intermediary 15 rejected their call attempt. The call will not be answered. As a 16 6xx code, the caller will be aware that future attempts to contact 17 the same UAS will likely fail. The present use case driving the need 18 for the 608 response code is when the intermediary is an analytics 19 engine. In this case, the rejection is by a machine or other 20 process. This contrasts with the 607 (Unwanted) SIP response code, 21 which a human at the target UAS indicated the call was not wanted. 22 In some jurisdictions this distinction is important. This document 23 also defines the use of the Call-Info header in 608 responses to 24 enable rejected callers to contact entities that blocked their calls 25 in error. This provides a remediation mechanism for legal callers 26 that find their calls blocked. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 2, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 65 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8 66 3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8 67 3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 8 69 3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9 70 3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9 71 3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9 72 3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10 73 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 11 75 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 14 76 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 15 77 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 15 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 17 80 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 17 81 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17 82 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 18 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 8.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 The IETF has been addressing numerous issues surrounding how to 93 handle unwanted and, depending on the jurisdiction, illegal calls 94 [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] 95 address the cryptographic signing and attestation, respectively, of 96 signaling to ensure the integrity and authenticity of the asserted 97 caller identity. 99 This document describes a new SIP response code, 608, which allows 100 calling parties to learn that an intermediary rejected their call. 101 As described below, we need a distinct indicator to differentiate 102 between a user rejection and an intermediary's rejection of a call. 103 In some jurisdictions, calls, even if unwanted by the user, may not 104 be blocked unless there is an explicit user request. Moreover, users 105 may misidentify the nature of a caller. 107 For example, a legitimate caller may call a user who finds the call 108 to be unwanted. However, instead of marking the call as unwanted, 109 the user may mark the call as illegal. With that information, an 110 analytics engine may determine that all calls from that source should 111 be blocked. However, in some jurisdictions blocking calls from that 112 source for other users may not be legal. Likewise, one can envision 113 jurisdictions that allow an operator to block such calls, but only if 114 there is a remediation mechanism in place to address false positives. 116 Some call blocking services may return responses such as 604 (Does 117 Not Exist Anywhere). This might be a strategy to try to get a 118 destination's address removed from a calling database. However, 119 other network elements might also interpret this to mean the user 120 truly does not exist and might result in the user not being able to 121 receive calls from anyone, even if wanted. In many jurisdictions, 122 providing such false signaling is also illegal. 124 The 608 response code addresses this need of remediating falsely 125 blocked calls. Specifically, this code informs the UAC that an 126 intermediary blocked the call and provides a redress mechanism that 127 allows callers to contact the operator of the intermediary. 129 In the current call handling ecosystem, users can explicitly reject a 130 call or later mark a call as being unwanted by issuing a 607 SIP 131 response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the 132 operation of the 607 SIP response code. The UAS indicates the call 133 was unwanted. As RFC8197 explains, not only does the called party 134 desire to reject that call, they can let their proxy know that they 135 consider future calls from that source unwanted. Upon receipt of the 136 607 response from the UAS, the proxy may send call information to a 137 call analytics engine. For various reasons described in RFC8197, if 138 a network operator receives multiple reports of unwanted calls, that 139 may indicate that the entity placing the calls is likely to be a 140 source of unwanted calls for many people. As such, other customers 141 of the service provider may want the service provider to 142 automatically reject calls on their behalf. 144 Another value of the 607 rejection is presuming the proxy forwards 145 the response code to the UAC, the calling UAC or intervening proxies 146 will also learn the user is not interested in receiving calls from 147 that sender. 149 +-----------+ 150 | Call | 151 | Analytics | 152 | Engine | 153 +-----------+ 154 ^ | (likely not SIP) 155 | v 156 +-----------+ 157 +-----+ 607 | Called | 607 +-----+ 158 | UAC | <--------- | Party | <-------- | UAS | 159 +-----+ | Proxy | +-----+ 160 +-----------+ 162 Figure 1: Unwanted (607) Call Flow 164 For calls rejected with a 607 from a legitimate caller, receiving a 165 607 response code can inform the caller to stop attempting to call 166 the user. Moreover, if a legitimate caller believes the user is 167 rejecting their calls in error, they can use other channels to 168 contact the user. For example, if a pharmacy calls a user to let 169 them know their prescription is available for pickup and the user 170 mistakenly thinks the call is unwanted and issues a 607 response 171 code, the pharmacy, having an existing relationship with the 172 customer, can send the user an email or push a note to the pharmacist 173 to ask the customer to consider not rejecting their calls in the 174 future. 176 Many systems that allow the user to mark the call unwanted (e.g., 177 with the 607 response code) also allow the user to change their mind 178 and unmark such calls. This mechanism is relatively easy to 179 implement as the user usually has a direct relationship with the 180 service provider that is blocking calls. 182 However, things become more complicated if an intermediary, such as a 183 third-party provider of call management services that classifies 184 calls based on the relative likelihood that the call is unwanted, 185 misidentifies the call as unwanted. Figure 3 shows this case. Note 186 that the UAS typically does not receive an INVITE since the called 187 party proxy rejects the call on behalf of the user. In this 188 situation, it would be beneficial for the caller to learn who 189 rejected the call, so they can correct the misidentification. 191 +--------+ +-----------+ 192 | Called | | Call | 193 +-----+ | Party | | Analytics | +-----+ 194 | UAC | | Proxy | | Engine | | UAS | 195 +-----+ +--------+ +-----------+ +-----+ 196 | INVITE | | | 197 | --------------> | INVITE | | 198 | | ------------------------------> | 199 | | | | 200 | | | 607 | 201 | | <------------------------------ | 202 | | | | 203 | | Unwanted call | | 204 | 607 | -----------------> | | 205 | <-------------- | indicator | | 206 | | | | 208 Figure 2: Unwanted (607) Ladder Diagram 210 +-----------+ 211 | Call | 212 | Analytics | 213 | Engine | 214 +-----------+ 215 ^ | (likely not SIP) 216 | v 217 +-----------+ 218 +-----+ 608 | Called | +-----+ 219 | UAC | <--------- | Party | | UAS | 220 +-----+ | Proxy | +-----+ 221 +-----------+ 223 Figure 3: Rejected (608) Call Flow 225 In this situation, one might be tempted to have the intermediary use 226 the 607 response code. 607 indicates to the caller the subscriber 227 does not want the call. However, RFC8197 specifies that one of the 228 uses of 607 is to inform analytics engines that a user (human) has 229 rejected a call. The problem here is network elements downstream 230 from the intermediary might interpret the 607 as a user (human) 231 marking the call as unwanted, as opposed to a statistical, machine 232 learning, vulnerable to the base rate fallacy [BaseRate] algorithm 233 rejecting the call. In other words, those downstream entities should 234 not be relying on another entity 'deciding' the call is unwanted. By 235 distinguishing between a (human) user rejection and an intermediary 236 engine's statistical rejection, a downstream network element that 237 sees a 607 response code can weight it as a human rejection in its 238 call analytics. 240 It is useful for blocked callers to have a redress mechanism. One 241 can imagine that some jurisdictions will require it. However, we 242 must be mindful that most of the calls that will be blocked will, in 243 fact, be illegal and eligible for blocking. Thus, providing 244 alternate contact information for a user would be counterproductive 245 to protecting that user from illegal communications. This is another 246 reason we do not propose to simply allow alternate contact 247 information in a 607 response message. 249 One might ask why we cannot use the same mechanism an analytics 250 service provider offers their customers that lets them correct a call 251 blocked in error? The reason is while there is an existing 252 relationship between the customer (called party) and the analytics 253 service provider, it is unlikely there is a relationship between the 254 caller and the analytics service provider. Moreover, there are 255 numerous call blocking providers in the ecosystem. As such, we need 256 a mechanism for indicating an intermediary rejected a call that also 257 provides contact information for the operator of that intermediary, 258 without exposing the target user's contact information. 260 The protocol described in this document uses existing IETF protocol 261 mechanisms for specifying the redress mechanism. In the SIP header 262 passed back to the UAC, we send additional information specifying a 263 redress address. We choose to encode the redress address using jCard 264 [RFC7095]. Conveniently, we use jCard rather than vCard [RFC6350] as 265 we have a standard marshaling mechanism for creating a canonical 266 representation of a JSON [RFC8259] object, such as a jCard, and a 267 standard presentation format for such an object, namely JWS 268 [RFC7515]. The SIP community is familiar with this concept as it is 269 the mechanism used by STIR [RFC8224]. 271 The jCard encoding might seem unnecessary at first, but it is 272 essential to preventing potential network attacks. Suppose, for 273 example, that the redress address was simply passed as a header 274 value. One can imagine an adverse agent that maliciously spoofs a 275 608 response with the same redress address to a large number of 276 active callers, who may then all send redress requests to the 277 specified address (the basis for a denial-of-service attack). The 278 process would occur as follows: (1) a malicious agent senses INVITE 279 requests from a variety UACs and (2) spoofs 608 responses with an 280 unsigned redress address before the intended receivers can respond, 281 causing (3) the UACs to all contact the redress address at once. The 282 jCard encoding allows the UAC to verify the blocking intermediary's 283 identity before contacting the redress address. This guards against 284 a malicious agent spoofing 608 responses, preventing the denial-of- 285 service attack. Thus if the jCard address is unreachable or 286 undecipherable, either (1) a malicious agent is lying about the jCard 287 or (2) the redress mechanism is misconfigured. 289 2. Terminology 291 This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 292 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 293 "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only 294 when, they appear in all capitals, as shown here. 296 3. Protocol Operation 298 For clarity, this section uses the term 'intermediary' as the entity 299 that acts as a SIP User Agent Server (UAS) on behalf of the user in 300 the network, as opposed to the user's UAS (colloquially, but not 301 necessarily, their phone). The intermediary could be a back-to-back 302 user agent (B2BUA) or a SIP Proxy. 304 Figure 4 shows an overview of the call flow for a rejected call. 306 +--------+ +-----------+ 307 | Called | | Call | 308 +-----+ | Party | | Analytics | +-----+ 309 | UAC | | Proxy | | Engine | | UAS | 310 +-----+ +--------+ +-----------+ +-----+ 311 | INVITE | | | 312 | --------------> | Information from | | 313 | | -----------------> | | 314 | | INVITE | | 315 | | Reject | | 316 | 608 | <----------------- | | 317 | <-------------- | call | | 318 | | | | 320 Figure 4: Rejected (608) Ladder Diagram 322 3.1. Intermediary Operation 324 An intermediary MAY issue the 608 response code in a failure response 325 for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP 326 [RFC3261] request to indicate that an intermediary rejected the 327 offered communication as unwanted by the user. An intermediary MAY 328 issue the 608 as the value of the "cause" parameter of a SIP reason- 329 value in a Reason header field [RFC3326]. 331 If an intermediary issues a 608 code and there are not indicators the 332 calling party will use the contents of the Call-Info header for 333 malicious purposes (see Section 6), the intermediary MUST include a 334 Call-Info header in the response. 336 If there is a Call-Info header, it MUST have the 'purpose' parameter 337 of 'jwscard'. The value of the Call-Info header MUST refer to a 338 valid JWS [RFC7515] encoding of a jCard [RFC7095] object. 340 Proxies need to be mindful that a downstream intermediary may reject 341 the attempt with a 608 while other paths may still be in progress. 342 In this situation, the requirements stated in Section 16.7 of RFC3261 343 [RFC3261] apply. Specifically, the proxy should cancel pending 344 transactions and must not create any new branches. Note this is not 345 a new requirement but simply pointing out the existing 6xx protocol 346 mechanism in SIP. 348 3.2. jCard Construction 350 The intermediary constructs the JWS as follows. 352 3.2.1. JOSE Header 354 The JOSE header MUST include the typ, alg, and x5u parameters from 355 JWS [RFC7515]. The typ parameter MUST have the value "vcard+json". 356 Implementations MUST support ES256 as JWA [RFC7518] defines it, and 357 MAY support other registered signature algorithms. Finally, the x5u 358 parameter MUST be a URI that resolves to the public key certificate 359 corresponding to the key used to digitally sign the JWS. 361 3.2.2. JWT Payload 363 The payload contains two JSON values. The first JWT claim that MUST 364 be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be 365 set to the date and time of the issuance of the 608 response. This 366 mandatory component protects the response from replay attacks. 368 The second JWT claim that MUST be present is the jcard claim. 369 Section 5.3 describes the registration. In the construction of the 370 jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, 371 TEL, or ADR properties. UACs supporting this specification MUST be 372 prepared to receive a full jCard. Call originators (at the UAC) can 373 use the information returned by the jCard to contact the intermediary 374 that rejected the call to appeal the intermediary's blocking of the 375 call attempt. What the intermediary does if the blocked caller 376 contacts the intermediary is outside the scope of this document. 378 3.2.3. JWS Signature 380 JWS [RFC7515] specifies the procedure for calculating the signature 381 over the jCard JWT. Section 4 of this document has a detailed 382 example on constructing the JWS, including the signature. 384 3.3. UAC Operation 386 A UAC conforming to this specification MUST include the sip.608 387 feature capability tag in the INVITE request. 389 Upon receiving a 608 response, UACs perform normal SIP processing for 390 6xx responses. 392 3.4. Legacy Interoperation 394 If the UAC indicates support for 608 and the intermediary issues a 395 608, life is good as the UAC will receive all the information it 396 needs to remediate an erroneous block by an intermediary. However, 397 what if the UAC does not understand 608? For example, how can we 398 support callers from a legacy, non-SIP public switched network 399 connecting to the SIP network via a media gateway? 401 We address this situation by having the first network element that 402 conforms with this specification play an announcement in the media. 403 See Section 3.5 for requirements on the announcement. The simple 404 rule is a network element that inserts the sip.608 feature capability 405 MUST be able to convey at a minimum how to contact the operator of 406 the intermediary that rejected the call attempt. 408 The degenerate case is the intermediary is the only element that 409 understands the semantics of the 608 response code. Obviously, any 410 SIP device will understand that a 608 response code is a 6xx error. 411 However, there are no other elements in the call path that understand 412 the meaning of the value of the Call-Info header. The intermediary 413 knows this is the case as the INVITE request will not have the 414 sip.608 feature capability. In this case, one can consider the 415 intermediary to be the element 'inserting' a virtual sip.608 feature 416 capability. If the caveats described in Section 3.5 and Section 6 do 417 not hold, the intermediary MUST play the announcement. 419 Now we take the case where a network element that understands the 608 420 response code receives an INVITE for further processing. A network 421 element conforming with this specification MUST insert the sip.608 422 feature capability, per the behaviors described in Section 4.2 of 423 [RFC6809]. 425 Do note that even if a network element plays an announcement 426 describing the contents of the 608 response message, the network 427 element MUST forward the 608 response code message as the final 428 response to the INVITE. 430 One aspect of using a feature capability is only the network elements 431 that will consume (UAC) or play an announcement (media gateway, SBC, 432 or proxy) need understand the sip.608 feature capability. All other 433 (existing) infrastructure can remain without modification, assuming 434 they are conformant to Section 16.6 of [RFC3261], specifically they 435 will pass headers such as "Feature-Capability: sip.608" unmodified. 437 3.5. Announcement Requirements 439 There are a few requirements on the element that will be doing the 440 announcement for legacy interoperation. 442 As noted above, the element that inserts the sip.608 feature 443 capability is responsible for conveying the information referenced by 444 the Call-Info header in the 608 response message. However, this 445 specification does not mandate the modality for conveying that 446 information. 448 Let us take the case where a telecommunications service provider 449 controls the element inserting the sip.608 feature capability. It 450 would be reasonable to expect the service provider would play an 451 announcement in the media path towards the UAC (caller). It is 452 important to note the network element should be mindful of the media 453 type requested by the UAC as it formulates the announcement. For 454 example, it would make sense for an INVITE that only indicated audio 455 codecs in the SDP [RFC4566] to result in an audio announcement. 456 However, if the INVITE only indicated a real-time text codec and the 457 network element is able to render the information in the requested 458 media format, the network element MUST send the information in a text 459 format, not an audio format. 461 It is also possible for the network element inserting the sip.608 462 feature capability to be under the control of the same entity that 463 controls the UAC. For example, a large call center might have legacy 464 UACs, but have a modern outbound calling proxy that understands the 465 full semantics of the 608 response code. In this case, it is enough 466 for the outbound calling proxy to digest the Call-Info information 467 and handle the information digitally, rather than 'transcoding' the 468 Call-Info information for presentation to the caller. 470 4. Examples 472 These examples are not normative, do not include all protocol 473 elements, and may have errors. Review the protocol documents for 474 actual syntax and semantics of the protocol elements. 476 4.1. Full Exchange 478 Given an INVITE (shamelessly taken from [SHAKEN]): 480 INVITE sip:+12155551213@tel.example1.net SIP/2.0 481 Max-Forwards: 69 482 Contact: 483 To: 484 From: "Alice" ;tag=614bdb40 485 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 486 P-Asserted-Identity: "Alice", 487 488 CSeq: 2 INVITE 489 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, 490 MESSAGE, OPTIONS 491 Content-Type: application/sdp 492 Date: Tue, 16 Aug 2016 19:23:38 GMT 493 Feature-Caps: *;+sip.608 494 Identity: 495 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I 496 joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC 497 J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI 498 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 499 IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n 500 Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC 501 A;info=;alg=ES256 502 Content-Length: 153 504 v=0 505 o=- 13103070023943130 1 IN IP4 192.0.2.177 506 c=IN IP4 192.0.2.177 507 t=0 0 508 m=audio 54242 RTP/AVP 0 509 a=sendrecv 511 An intermediary could reply: 513 SIP/2.0 608 Rejected 514 Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1 515 From: "Alice" ;tag=614bdb40 516 To: 517 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 518 CSeq: 2 INVITE 519 Call-Info: ;purpose=jwscard 521 The location https://block.example.net/complaint.json resolves to a 522 JWS. The JWS would be constructed as follows. 524 The JWS header of this example jCard could be: 526 { {"alg":"ES256"}, 527 {"typ":"vcard+json"}, 528 {"x5u":"https://certs.example.net/reject_key.cer"} } 530 Now, let us construct a minimal jCard. For this example, the jCard 531 refers the caller to an email address, bitbucket@blocker.example.net: 533 ["vcard", 534 [ 535 ["version", {}, "text", "4.0"], 536 ["fn", {}, "text", "Robocall Adjudication"], 537 ["email", {"type":"work"}, 538 "text", "bitbucket@blocker.example.net"] 539 ] 540 ] 542 With this jCard, we can now construct the JWT: 544 { 545 "iat":1546008698, 546 "jcard":["vcard", 547 [ 548 ["version", {}, "text", "4.0"], 549 ["fn", {}, "text", "Robocall Adjudication"], 550 ["email", {"type":"work"}, 551 "text", "bitbucket@blocker.example.net"] 552 ] 553 ] 554 } 556 In order to calculate the signature, we need to encode the JOSE 557 header and JWT into base64. As an implementation note, one can trim 558 whitespace in the JSON objects to save a few bytes. UACs MUST be 559 prepared to receive pretty printed, compact, or bizarrely formatted 560 JSON. For the purposes of this example, we leave the objects with 561 pretty whitespace. Speaking of pretty vs. machine formatting, these 562 examples have line breaks in the base64 encodings for ease of 563 publication in the RFC format. The specification of base64 allows 564 for these line breaks and the decoded text works just fine. However, 565 those extra line break octets would affect the calculation of the 566 signature. As such, implementations MUST NOT insert line breaks into 567 the base64 encodings of the JOSE header or JWT. This also means UACs 568 MUST be prepared to receive arbitrarily long octet streams from the 569 URI referenced by the Call-Info SIP header. 571 base64 of JOSE header: 572 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 573 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 574 fQo= 576 base64 of JWT: 577 ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK 578 ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu 579 Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb 580 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 581 IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K 583 In this case, the object to be signed (remembering this is just a 584 single, long line; the line breaks are for ease of review but do not 585 appear in the actual text being signed is as follows: 587 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 588 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 589 fQo= 590 . 591 ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK 592 ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu 593 Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb 594 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 595 IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K 597 We use the following X.509 PKCS #8-encoded ECDSA private key, also 598 shamelessly taken from [SHAKEN]), as an example key for signing the 599 hash of the above text. Do NOT use this key in real life! It is for 600 exemplary purposes only. At the very least, we would strongly 601 recommend the key being encrypted at rest. 603 -----BEGIN PRIVATE KEY----- 604 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy 605 qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW 606 ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh 607 -----END PRIVATE KEY----- 609 The resulting JWS, using the above key on the above object, renders 610 the following ECDSA P-256 SHA-256 digital signature. 612 MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5ehMOwjM 613 TS+skjf1163ihH5+yIHQS3quklEt/9o= 615 Thus, the JWS stored at https://blocker.example.net/complaints.json, 616 would contain: 618 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 619 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 620 fQo=.ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICA 621 gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB 622 bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA 623 gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ 624 0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB 625 dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e 626 hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o= 628 4.2. Web Site jCard 630 For an intermediary that provides a Web site for adjudication, the 631 jCard could contain the following. Note the calculation of the JWS 632 is not shown; the URI reference in the Call-Info header would be to 633 the JWS of the signed jCard. 635 ["vcard", 636 [ 637 ["version", {}, "text", "4.0"], 638 ["fn", {}, "text", "Robocall Adjudication"], 639 ["url", {"type":"work"}, 640 "text", "https://blocker.example.net/adjudication-form"] 641 ] 642 ] 644 4.3. Multi-modal jCard 646 For an intermediary that provides a telephone number and a postal 647 address, the jCard could contain the following. Note the calculation 648 of the JWS is not shown; the URI reference in the Call-Info header 649 would be to the JWS of the signed jCard. 651 ["vcard", 652 [ 653 ["version", {}, "text", "4.0"], 654 ["fn", {}, "text", "Robocall Adjudication"], 655 ["adr", {"type":"work"}, "text", 656 ["Argument Clinic", 657 "12 Main St","Anytown","AP","000000","Somecountry"] 658 ] 659 ["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"] 660 ] 661 ] 663 Note that it is up to the UAC to decide which jCard contact modality, 664 if any, it will use. 666 4.4. Legacy Interoperability 668 Figure 5 depicts a call flow illustrating legacy interoperability. 669 In this non-normative example, we see a UAC that does not support the 670 full semantics for 608. However, there is an SBC that does support 671 608. Per RFC6809 [RFC6809], the SBC can insert "*;+sip.608" into the 672 Feature-Caps header for the INVITE. When the intermediary, labeled 673 "Called Party Proxy" in the figure, rejects the call, it knows it can 674 simply perform the processing described in this document. Since the 675 intermediary saw the sip.608 feature capability, it knows it does not 676 need to send any media describing whom to contact in the event of an 677 erroneous rejection. 679 +---------+ 680 | Call | 681 |Analytics| 682 | Engine | 683 +---------+ 684 ^ | 685 | v 686 +---------+ 687 | Called | +-----+ +-----+ +---+ +-----+ +---+ 688 | Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC| 689 | Proxy | +-----+ +-----+ +---+ +-----+ +---+ 690 +---------+ | | 691 | | INVITE | 692 | INVITE |<--------------------| 693 |<-----------------------------------| | 694 | Feature-Caps: *;+sip.608 | | 695 | | | 696 | 608 Rejected | | 697 |----------------------------------->| 183 | 698 | Call-Info: <...> |-------------------->| 699 | [path for Call-Info elided | SDP for media | 700 | for illustration purposes] | | 701 | |=== Announcement ===>| 702 | | | 703 | | 608 | 704 | |-------------------->| 705 | | Call-Info: <...> | 707 Figure 5: Legacy Operation 709 When the SBC receives the 608 response code, it correlates that with 710 the original INVITE from the UAC. The SBC remembers that it inserted 711 the sip.608 feature capability, which means it is responsible for 712 somehow alerting the UAC the call failed and whom to contact. At 713 this point the SBC can play a prompt, either natively or through a 714 mechanism such as NETANN [RFC4240], that sends the relevant 715 information in the appropriate media to the UAC. 717 As an example, the SBC could extract the FN and TEL jCard fields and 718 play something like a special information tone (see Telcordia SR-2275 719 [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section 720 7), followed by "Your call has been rejected by ...", followed by a 721 text-to-speech translation of the FN text, followed by "You can reach 722 them on", followed by a text-to-speech translation of the telephone 723 number in the TEL field. 725 Note the SBC also still sends the full 608 response code, including 726 the Call-Info header, towards the UAC. 728 5. IANA Considerations 730 5.1. SIP Response Code 732 This document defines a new SIP response code, 608 in the "Response 733 Codes" subregistry of the "Session Initiation Protocol (SIP) 734 Parameters" registry defined in [RFC3261]. 736 Response code: 608 738 Description: Rejected 740 Reference: [RFCXXXX] 742 5.2. SIP Feature-Capability Indicator 744 This document defines the feature capability sip.608 in the "SIP 745 Feature-Capability Indicator Registration Tree" registry defined in 746 [RFC6809]. 748 Name: sip.608 750 Description: This feature capability indicator, when included in a 751 Feature-Caps header field of an INVITE request, indicates that the 752 entity associated with the indicator will be responsible for 753 indicating to the caller any information contained in the 608 SIP 754 response code, specifically the value referenced by the Call-Info 755 header. 757 Reference: [RFCXXXX] 759 5.3. JSON Web Token Claim 761 This document defines the new JSON Web Token claim in the "JSON Web 762 Token Claims" sub-registry created by [RFC7519]. Section 3.2.2 763 defines the syntax. The required information is: 765 Claim Name: jcard 767 Claim Description: jCard data 769 Change Controller: IESG 771 Reference: [RFCXXXX], [RFC7095] 773 5.4. Call-Info Purpose 775 This document defines the new predefined value "jwscard" for the 776 "purpose" header field parameter of the Call-Info header field. This 777 modifies the registry header field parameters and parameter values by 778 adding this RFC as a reference to the line for the header field 779 "Call-Info" and parameter name "purpose": 781 Header Field: Call-Info 783 Parameter Name: purpose 785 Predefined Values: Yes 787 Reference: [RFCXXXX] 789 6. Security Considerations 791 Intermediary operators need to be mindful of whom they are sending 792 the 608 response. There is a risk that a truly malicious caller is 793 being rejected. This raises two issues. The first is the caller, 794 now alerted that the call is being automatically rejected, may change 795 their call behavior to defeat call blocking systems. The second, and 796 more significant risk, is that by providing a contact in the Call- 797 Info field, the intermediary may be giving the malicious caller a 798 vector for attack. In other words, the intermediary will be 799 publishing an address that a malicious actor may use to launch an 800 attack on the intermediary. Because of this, intermediary operators 801 may wish to configure their response to only include a Call-Info 802 field for INVITE or other initiating methods that are signed and pass 803 validation by STIR [RFC8224]. 805 Another risk is for an attacker to purposely not include the sip.608 806 feature capability in a flood of INVITE requests, direct those 807 requests to proxies known to insert the sip.608 feature, and direct 808 the SDP to a victim device. Because the mechanism described here can 809 result in an audio file being sent to the target of the Contact 810 header, an attacker could use the mechanism described by this 811 document as an amplification attack, given a SIP INVITE can be under 812 1 kilobyte and an audio file can be hundreds of kilobytes. One 813 remediation for this is for devices that insert a sip.608 feature 814 capability only transmit media to what is highly likely to be the 815 actual source of the call attempt. A method for this is to only play 816 media in response to an INVITE that is signed and passed validation 817 by STIR [RFC8224]. 819 Yet another risk is a malicious entity or the intermediary itself can 820 generate a malicious 608 response with a jCard referring to a 821 malicious agent. For example, the recipient of a 608 may receive a 822 TEL URI in the vCard. When the recipient calls that address, the 823 malicious agent could ask for personally identifying information. 824 However, instead of using that information to verify the recipient's 825 identity, they are pharming the information for nefarious ends. As 826 such, we strongly recommend the recipient validates to whom they are 827 communicating with if asking to adjudicate an erroneously rejected 828 call attempt. Since we may also be concerned about intermediate 829 nodes modifying contact information, we can address both of these 830 issues with a single solution. The remediation is to require the 831 intermediary to sign the jCard. Signing the jCard provides integrity 832 protection. In addition, one can imagine mechanisms such as used by 833 SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism 834 for traceback to the entity issuing the jCard, for example tying the 835 identity of the subject of the certificate to the To field of the 836 initial SIP request, as if the intermediary was vouching for the From 837 field of a SIP request with that identity. 839 Since the decision of whether to include Call-Info in the 608 840 response is a matter of policy, one thing to consider is whether a 841 legitimate caller can ascertain whom to contact without such 842 information being included in the 608. For example, in some 843 jurisdictions, if the terminating service provider is the 844 intermediary, the caller can lookup who the terminating service 845 provider is based on the routing information for the dialled number. 846 As such, the Call-Info jCard could be redundant information. 847 However, the factors going into a particular service provider's or 848 jourisdiction's choice of whether or not to include Call-Info is 849 outside the scope of this document. 851 7. Acknowledgements 853 This document liberally lifts from [RFC8197] in its text and 854 structure. However, the mechanism and purpose of 608 is quite 855 different than 607. Any errors are the current editor's and not the 856 editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ 857 Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on 858 improving the draft. Tolga's suggestion to provide a mechanism for 859 legacy interoperability served to expand the draft by 50%. In 860 addition, Tolga came up with the jCard attack. Finally, Christer 861 Holmberg as always provided a close reading and caught a SIP feature 862 capability bug. 864 Finally, Bhavik Nagda provided clarifying edits as well and more 865 especially wrote and tested an implementation of the 608 response 866 code in Kamailio. Code is available at . 869 8. References 871 8.1. Normative References 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, 875 DOI 10.17487/RFC2119, March 1997, 876 . 878 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 879 A., Peterson, J., Sparks, R., Handley, M., and E. 880 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 881 DOI 10.17487/RFC3261, June 2002, 882 . 884 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 885 Header Field for the Session Initiation Protocol (SIP)", 886 RFC 3326, DOI 10.17487/RFC3326, December 2002, 887 . 889 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 890 Indicate Support of Features and Capabilities in the 891 Session Initiation Protocol (SIP)", RFC 6809, 892 DOI 10.17487/RFC6809, November 2012, 893 . 895 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 896 DOI 10.17487/RFC7095, January 2014, 897 . 899 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 900 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 901 2015, . 903 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 904 DOI 10.17487/RFC7518, May 2015, 905 . 907 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 908 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 909 . 911 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 912 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 913 May 2017, . 915 8.2. Informative References 917 [BaseRate] 918 Bar-Hillel, M., "The Base-Rate Fallacy in Probability 919 Judgements", 4 1977, 920 . 922 [ITU.E.180.1998] 923 International Telecommunications Union, "Technical 924 characteristics of tones for the telephone service", 925 ITU Recommendation E.180/Q.35, March 1998. 927 [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic 928 Network Media Services with SIP", RFC 4240, 929 DOI 10.17487/RFC4240, December 2005, 930 . 932 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 933 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 934 July 2006, . 936 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 937 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 938 January 2008, . 940 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 941 DOI 10.17487/RFC6350, August 2011, 942 . 944 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 945 Telephone Identity Problem Statement and Requirements", 946 RFC 7340, DOI 10.17487/RFC7340, September 2014, 947 . 949 [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 950 RFC 8197, DOI 10.17487/RFC8197, July 2017, 951 . 953 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 954 "Authenticated Identity Management in the Session 955 Initiation Protocol (SIP)", RFC 8224, 956 DOI 10.17487/RFC8224, February 2018, 957 . 959 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 960 Interchange Format", STD 90, RFC 8259, 961 DOI 10.17487/RFC8259, December 2017, 962 . 964 [SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS) 965 and the SIP Forum, "Signature-based Handling of Asserted 966 information using toKENs (SHAKEN)", ATIS 1000074, 1 2017, 967 . 971 [SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR- 972 2275, October 2000. 974 Authors' Addresses 976 Eric W. Burger 977 Georgetown University 978 37th & O St, NW 979 Washington, DC 20057 980 USA 982 Email: eburger@standardstrack.com 984 Bhavik Nagda 985 Massachusetts Institute of Technology 986 77 Massachusetts Avenue 987 Cambridge, MA 02139 988 USA 990 Email: nagdab@gmail.com