idnits 2.17.1 draft-ietf-sipcore-rejected-03.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 (February 3, 2019) is 1909 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 789, 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: August 7, 2019 Massachusetts Institute of Technology 6 February 3, 2019 8 A Session Initiation Protocol (SIP) Response Code for Rejected Calls 9 draft-ietf-sipcore-rejected-03 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 August 7, 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 . . . . . . . . . . . . . . . . . . . . . 9 68 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 15 76 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 15 77 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . 18 82 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 18 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 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 As a matter of principle, this document uses the term "UNLESS" to 297 distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" 298 means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. 299 Burger's Law of Protocol Meaningless Terms. 301 3. Protocol Operation 303 For clarity, this section uses the term 'intermediary' as the entity 304 that acts as a SIP User Agent Server (UAS) on behalf of the user in 305 the network, as opposed to the user's UAS (colloquially, but not 306 necessarily, their phone). The intermediary could be a back-to-back 307 user agent (B2BUA) or a SIP Proxy. 309 Figure 4 shows an overview of the call flow for a rejected call. 311 +--------+ +-----------+ 312 | Called | | Call | 313 +-----+ | Party | | Analytics | +-----+ 314 | UAC | | Proxy | | Engine | | UAS | 315 +-----+ +--------+ +-----------+ +-----+ 316 | INVITE | | | 317 | --------------> | Information from | | 318 | | -----------------> | | 319 | | INVITE | | 320 | | Reject | | 321 | 608 | <----------------- | | 322 | <-------------- | call | | 323 | | | | 325 Figure 4: Rejected (608) Ladder Diagram 327 3.1. Intermediary Operation 329 An intermediary MAY issue the 608 response code in a failure response 330 for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP 331 [RFC3261] request to indicate that an intermediary rejected the 332 offered communication as unwanted by the user. An intermediary MAY 333 issue the 608 as the value of the "cause" parameter of a SIP reason- 334 value in a Reason header field [RFC3326]. 336 If an intermediary issues a 608 code, the intermediary SHOULD include 337 a Call-Info header in the response, UNLESS there are indicators the 338 calling party will use the contents of the Call-Info header for 339 malicious purposes (see Section 6). 341 If there is a Call-Info header, it MUST have the 'purpose' parameter 342 of 'jwscard'. The value of the Call-Info header MUST refer to a 343 valid JWS [RFC7515] encoding of a jCard [RFC7095] object. 345 Proxies need to be mindful that a downstream intermediary may reject 346 the attempt with a 608 while other paths may still be in progress. 347 In this situation, the requirements stated in Section 16.7 of RFC3261 348 [RFC3261] apply. Specifically, the proxy should cancel pending 349 transactions and must not create any new branches. Note this is not 350 a new requirement but simply pointing out the existing 6xx protocol 351 mechanism in SIP. 353 3.2. jCard Construction 355 The intermediary constructs the JWS as follows. 357 3.2.1. JOSE Header 359 The JOSE header MUST include the typ, alg, and x5u parameters from 360 JWS [RFC7515]. The typ parameter MUST have the value "vcard+json". 361 Implementations MUST support ES256 as JWA [RFC7518] defines it, and 362 MAY support other registered signature algorithms. Finally, the x5u 363 parameter MUST be a URI that resolves to the public key certificate 364 corresponding to the key used to digitally sign the JWS. 366 3.2.2. JWT Payload 368 The payload contains two JSON values. The first JWT claim that MUST 369 be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be 370 set to the date and time of the issuance of the 608 response. This 371 mandatory component protects the response from replay attacks. 373 The second JWT claim that MUST be present is the jcard claim. 374 Section 5.3 describes the registration. In the construction of the 375 jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, 376 TEL, or ADR properties. UACs supporting this specification MUST be 377 prepared to receive a full jCard. Call originators (at the UAC) can 378 use the information returned by the jCard to contact the intermediary 379 that rejected the call to appeal the intermediary's blocking of the 380 call attempt. What the intermediary does if the blocked caller 381 contacts the intermediary is outside the scope of this document. 383 3.2.3. JWS Signature 385 JWS [RFC7515] specifies the procedure for calculating the signature 386 over the jCard JWT. Section 4 of this document has a detailed 387 example on constructing the JWS, including the signature. 389 3.3. UAC Operation 391 A UAC conforming to this specification MUST include the sip.608 392 feature capability tag in the INVITE request. 394 Upon receiving a 608 response, UACs perform normal SIP processing for 395 6xx responses. 397 3.4. Legacy Interoperation 399 If the UAC indicates support for 608 and the intermediary issues a 400 608, life is good as the UAC will receive all the information it 401 needs to remediate an erroneous block by an intermediary. However, 402 what if the UAC does not understand 608? For example, how can we 403 support callers from a legacy, non-SIP public switched network 404 connecting to the SIP network via a media gateway? 405 We address this situation by having the first network element that 406 conforms with this specification play an announcement in the media. 407 See Section 3.5 for requirements on the announcement. The simple 408 rule is a network element that inserts the sip.608 feature capability 409 MUST be able to convey at a minimum how to contact the operator of 410 the intermediary that rejected the call attempt. 412 The degenerate case is the intermediary is the only element that 413 understands the semantics of the 608 response code. Obviously, any 414 SIP device will understand that a 608 response code is a 6xx error. 415 However, there are no other elements in the call path that understand 416 the meaning of the value of the Call-Info header. The intermediary 417 knows this is the case as the INVITE request will not have the 418 sip.608 feature capability. In this case, one can consider the 419 intermediary to be the element 'inserting' a virtual sip.608 feature 420 capability. As such, the intermediary SHOULD play the announcement, 421 UNLESS the caveats described in Section 3.5 and Section 6 hold. 423 Now we take the case where a network element that understands the 608 424 response code receives an INVITE for further processing. A network 425 element conforming with this specification MUST insert the sip.608 426 feature capability, per the behaviors described in Section 4.2 of 427 [RFC6809]. 429 Do note that even if a network element plays an announcement 430 describing the contents of the 608 response message, the network 431 element MUST forward the 608 response code message as the final 432 response to the INVITE. 434 One aspect of using a feature capability is only the network elements 435 that will consume (UAC) or play an announcement (media gateway, SBC, 436 or proxy) need understand the sip.608 feature capability. All other 437 (existing) infrastructure can remain without modification, assuming 438 they are conformant to Section 16.6 of [RFC3261], specifically they 439 will pass headers such as "Feature-Capability: sip.608" unmodified. 441 3.5. Announcement Requirements 443 There are a few requirements on the element that will be doing the 444 announcement for legacy interoperation. 446 As noted above, the element that inserts the sip.608 feature 447 capability is responsible for conveying the information referenced by 448 the Call-Info header in the 608 response message. However, this 449 specification does not mandate the modality for conveying that 450 information. 452 Let us take the case where a telecommunications service provider 453 controls the element inserting the sip.608 feature capability. It 454 would be reasonable to expect the service provider would play an 455 announcement in the media path towards the UAC (caller). It is 456 important to note the network element should be mindful of the media 457 type requested by the UAC as it formulates the announcement. For 458 example, it would make sense for an INVITE that only indicated audio 459 codecs in the SDP [RFC4566] to result in an audio announcement. 460 However, if the INVITE only indicated a real-time text codec, the 461 network element SHOULD send the information in a text format, not an 462 audio format, unless the network element is unable to render the 463 information in the requested media format. 465 It is also possible for the network element inserting the sip.608 466 feature capability to be under the control of the same entity that 467 controls the UAC. For example, a large call center might have legacy 468 UACs, but have a modern outbound calling proxy that understands the 469 full semantics of the 608 response code. In this case, it is enough 470 for the outbound calling proxy to digest the Call-Info information 471 and handle the information digitally, rather than 'transcoding' the 472 Call-Info information for presentation to the caller. 474 4. Examples 476 These examples are not normative, do not include all protocol 477 elements, and may have errors. Review the protocol documents for 478 actual syntax and semantics of the protocol elements. 480 4.1. Full Exchange 482 Given an INVITE (shamelessly taken from [SHAKEN]): 484 INVITE sip:+12155551213@tel.example1.net SIP/2.0 485 Max-Forwards: 69 486 Contact: 487 To: 488 From: "Alice" ;tag=614bdb40 489 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 490 P-Asserted-Identity: "Alice", 491 492 CSeq: 2 INVITE 493 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, 494 MESSAGE, OPTIONS 495 Content-Type: application/sdp 496 Date: Tue, 16 Aug 2016 19:23:38 GMT 497 Feature-Caps: sip.608 498 Identity: 499 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I 500 joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC 501 J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI 502 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 503 IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n 504 Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC 505 A;info=;alg=ES256 506 Content-Length: 153 508 v=0 509 o=- 13103070023943130 1 IN IP4 192.0.2.177 510 c=IN IP4 192.0.2.177 511 t=0 0 512 m=audio 54242 RTP/AVP 0 513 a=sendrecv 515 An intermediary could reply: 517 SIP/2.0 608 Rejected 518 Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1 519 From: "Alice" ;tag=614bdb40 520 To: 521 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 522 CSeq: 2 INVITE 523 Call-Info: ;purpose=jwscard 525 The location https://block.example.net/complaint.json resolves to a 526 JWS. The JWS would be constructed as follows. 528 The JWS header of this example jCard could be: 530 { {"alg":"ES256"}, 531 {"typ":"vcard+json"}, 532 {"x5u":"https://certs.example.net/reject_key.cer"} } 534 Now, let us construct a minimal jCard. For this example, the jCard 535 refers the caller to an email address, bitbucket@blocker.example.net: 537 ["vcard", 538 [ 539 ["version", {}, "text", "4.0"], 540 ["fn", {}, "text", "Robocall Adjudication"], 541 ["email", {"type":"work"}, 542 "text", "bitbucket@blocker.example.net"] 543 ] 544 ] 546 With this jCard, we can now construct the JWT: 548 { 549 "iat":1546008698, 550 "jcard":["vcard", 551 [ 552 ["version", {}, "text", "4.0"], 553 ["fn", {}, "text", "Robocall Adjudication"], 554 ["email", {"type":"work"}, 555 "text", "bitbucket@blocker.example.net"] 556 ] 557 ] 558 } 560 In order to calculate the signature, we need to encode the JOSE 561 header and JWT into base64. As an implementation note, one can trim 562 whitespace in the JSON objects to save a few bytes. UACs MUST be 563 prepared to receive pretty printed, compact, or bizarrely formatted 564 JSON. For the purposes of this example, we leave the objects with 565 pretty whitespace. Speaking of pretty vs. machine formatting, these 566 examples have line breaks in the base64 encodings for ease of 567 publication in the RFC format. The specification of base64 allows 568 for these line breaks and the decoded text works just fine. However, 569 those extra line break octets would affect the calculation of the 570 signature. As such, implementations MUST NOT insert line breaks into 571 the base64 encodings of the JOSE header or JWT. This also means UACs 572 MUST be prepared to receive arbitrarily long octet streams from the 573 URI referenced by the Call-Info SIP header. 575 base64 of JOSE header: 576 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 577 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 578 fQo= 580 base64 of JWT: 581 ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK 582 ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu 583 Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb 584 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 585 IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K 587 In this case, the object to be signed (remembering this is just a 588 single, long line; the line breaks are for ease of review but do not 589 appear in the actual text being signed is as follows: 591 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 592 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 593 fQo= 594 . 595 ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK 596 ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu 597 Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb 598 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 599 IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K 601 We use the following X.509 PKCS #8-encoded ECDSA private key, also 602 shamelessly taken from [SHAKEN]), as an example key for signing the 603 hash of the above text. Do NOT use this key in real life! It is for 604 exemplary purposes only. At the very least, we would strongly 605 recommend the key being encrypted at rest. 607 -----BEGIN PRIVATE KEY----- 608 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy 609 qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW 610 ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh 611 -----END PRIVATE KEY----- 613 The resulting JWS, using the above key on the above object, renders 614 the following ECDSA P-256 SHA-256 digital signature. 616 MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5ehMOwjM 617 TS+skjf1163ihH5+yIHQS3quklEt/9o= 618 Thus, the JWS stored at https://blocker.example.net/complaints.json, 619 would contain: 621 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 622 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 623 fQo=.ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICA 624 gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB 625 bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA 626 gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ 627 0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB 628 dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e 629 hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o= 631 4.2. Web Site jCard 633 For an intermediary that provides a Web site for adjudication, the 634 jCard could contain the following. Note the calculation of the JWS 635 is not shown; the URI reference in the Call-Info header would be to 636 the JWS of the signed jCard. 638 ["vcard", 639 [ 640 ["version", {}, "text", "4.0"], 641 ["fn", {}, "text", "Robocall Adjudication"], 642 ["url", {"type":"work"}, 643 "text", "https://blocker.example.net/adjudication-form"] 644 ] 645 ] 647 4.3. Multi-modal jCard 649 For an intermediary that provides a telephone number and a postal 650 address, the jCard could contain the following. Note the calculation 651 of the JWS is not shown; the URI reference in the Call-Info header 652 would be to the JWS of the signed jCard. 654 ["vcard", 655 [ 656 ["version", {}, "text", "4.0"], 657 ["fn", {}, "text", "Robocall Adjudication"], 658 ["adr", {"type":"work"}, "text", 659 ["Argument Clinic", 660 "12 Main St","Anytown","AP","000000","Somecountry"] 661 ] 662 ["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"] 663 ] 664 ] 665 Note that it is up to the UAC to decide which jCard contact modality, 666 if any, it will use. 668 4.4. Legacy Interoperability 670 Figure 5 depicts a call flow illustrating legacy interoperability. 671 In this non-normative example, we see a UAC that does not support the 672 full semantics for 608. However, there is an SBC that does support 673 608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the 674 Feature-Caps header for the INVITE. When the intermediary, labeled 675 "Called Party Proxy" in the figure, rejects the call, it knows it can 676 simply perform the processing described in this document. Since the 677 intermediary saw the sip.608 feature capability, it knows it does not 678 need to send any media describing whom to contact in the event of an 679 erroneous rejection. 681 +---------+ 682 | Call | 683 |Analytics| 684 | Engine | 685 +---------+ 686 ^ | 687 | v 688 +---------+ 689 | Called | +-----+ +-----+ +---+ +-----+ +---+ 690 | Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC| 691 | Proxy | +-----+ +-----+ +---+ +-----+ +---+ 692 +---------+ | | 693 | | INVITE | 694 | INVITE |<--------------------| 695 |<-----------------------------------| | 696 | Feature-Caps: sip.608 | | 697 | | | 698 | 608 Rejected | | 699 |----------------------------------->| 183 | 700 | Call-Info: <...> |-------------------->| 701 | [path for Call-Info elided | SDP for media | 702 | for illustration purposes] | | 703 | |=== Announcement ===>| 704 | | | 705 | | 608 | 706 | |-------------------->| 707 | | Call-Info: <...> | 709 Figure 5: Legacy Operation 711 When the SBC receives the 608 response code, it correlates that with 712 the original INVITE from the UAC. The SBC remembers that it inserted 713 the sip.608 feature capability, which means it is responsible for 714 somehow alerting the UAC the call failed and whom to contact. At 715 this point the SBC can play a prompt, either natively or through a 716 mechanism such as NETANN [RFC4240], that sends the relevant 717 information in the appropriate media to the UAC. 719 As an example, the SBC could extract the FN and TEL jCard fields and 720 play something like a special information tone (see Telcordia SR-2275 721 [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section 722 7), followed by "Your call has been rejected by ...", followed by a 723 text-to-speech translation of the FN text, followed by "You can reach 724 them on", followed by a text-to-speech translation of the telephone 725 number in the TEL field. 727 Note the SBC also still sends the full 608 response code, including 728 the Call-Info header, towards the UAC. 730 5. IANA Considerations 732 5.1. SIP Response Code 734 This document defines a new SIP response code, 608 in the "Response 735 Codes" subregistry of the "Session Initiation Protocol (SIP) 736 Parameters" registry defined in [RFC3261]. 738 Response code: 608 740 Description: Rejected 742 Reference: [RFCXXXX] 744 5.2. SIP Feature-Capability Indicator 746 This document defines the feature capability sip.608 in the "SIP 747 Feature-Capability Indicator Registration Tree" registry defined in 748 [RFC6809]. 750 Name: sip.608 752 Description: This feature capability indicator, when included in a 753 Feature-Caps header field of an INVITE request, indicates that the 754 entity that inserted the sip.608 Feature-Caps value will be 755 responsible for indicating to the caller any information contained 756 in the 608 SIP response code, specifically the value referenced by 757 the Call-Info header 759 Reference: [RFCXXXX] 761 5.3. JSON Web Token Claim 763 This document defines the new JSON Web Token claim in the "JSON Web 764 Token Claims" sub-registry created by [RFC7519]. Section 3.2.2 765 defines the syntax. The required information is: 767 Claim Name: jcard 769 Claim Description: jCard data 771 Change Controller: IESG 773 Reference: [RFCXXXX], [RFC7095] 775 5.4. Call-Info Purpose 777 This document defines the new predefined value "jwscard" for the 778 "purpose" header field parameter of the Call-Info header field. This 779 modifies the registry header field parameters and parameter values by 780 adding this RFC as a reference to the line for the header field 781 "Call-Info" and parameter name "purpose": 783 Header Field: Call-Info 785 Parameter Name: purpose 787 Predefined Values: Yes 789 Reference: [RFCXXXX] 791 6. Security Considerations 793 Intermediary operators need to be mindful of whom they are sending 794 the 608 response. There is a risk that a truly malicious caller is 795 being rejected. This raises two issues. The first is the caller, 796 now alerted that the call is being automatically rejected, may change 797 their call behavior to defeat call blocking systems. The second, and 798 more significant risk, is that by providing a contact in the Call- 799 Info field, the intermediary may be giving the malicious caller a 800 vector for attack. In other words, the intermediary will be 801 publishing an address that a malicious actor may use to launch an 802 attack on the intermediary. Because of this, intermediary operators 803 may wish to configure their response to only include a Call-Info 804 field for INVITE or other initiating methods that are signed and pass 805 validation by STIR [RFC8224]. 807 Another risk is for an attacker to purposely not include the sip.608 808 feature capability in a flood of INVITE requests, direct those 809 requests to proxies known to insert the sip.608 feature, and direct 810 the SDP to a victim device. Because the mechanism described here can 811 result in an audio file being sent to the target of the Contact 812 header, an attacker could use the mechanism described by this 813 document as an amplification attack, given a SIP INVITE can be under 814 1 kilobyte and an audio file can be hundreds of kilobytes. One 815 remediation for this is for devices that insert a sip.608 feature 816 capability only transmit media to what is highly likely to be the 817 actual source of the call attempt. A method for this is to only play 818 media in response to an INVITE that is signed and passed validation 819 by STIR [RFC8224]. 821 Yet another risk is a malicious entity or the intermediary itself can 822 generate a malicious 608 response with a jCard referring to a 823 malicious agent. For example, the recipient of a 608 may receive a 824 TEL URI in the vCard. When the recipient calls that address, the 825 malicious agent could ask for personally identifying information. 826 However, instead of using that information to verify the recipient's 827 identity, they are pharming the information for nefarious ends. As 828 such, we strongly recommend the recipient validates to whom they are 829 communicating with if asking to adjudicate an erroneously rejected 830 call attempt. Since we may also be concerned about intermediate 831 nodes modifying contact information, we can address both of these 832 issues with a single solution. The remediation is to require the 833 intermediary to sign the jCard. Signing the jCard provides integrity 834 protection. In addition, one can imagine mechanisms such as used by 835 SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism 836 for traceback to the entity issuing the jCard, for example tying the 837 identity of the subject of the certificate to the To field of the 838 initial SIP request, as if the intermediary was vouching for the From 839 field of a SIP request with that identity. 841 Since the decision of whether to include Call-Info in the 608 842 response is a matter of policy, one thing to consider is whether a 843 legitimate caller can ascertain whom to contact without such 844 information being included in the 608. For example, in some 845 jurisdictions, if the terminating service provider is the 846 intermediary, the caller can lookup who the terminating service 847 provider is based on the routing information for the dialled number. 848 As such, the Call-Info jCard could be redundant information. 849 However, the factors going into a particular service provider's or 850 jourisdiction's choice of whether or not to include Call-Info is 851 outside the scope of this document. 853 7. Acknowledgements 855 This document liberally lifts from [RFC8197] in its text and 856 structure. However, the mechanism and purpose of 608 is quite 857 different than 607. Any errors are the current editor's and not the 858 editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ 859 Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on 860 improving the draft. Tolga's suggestion to provide a mechanism for 861 legacy interoperability served to expand the draft by 50%. In 862 addition, Tolga came up with the jCard attack. 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