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