idnits 2.17.1 draft-ietf-sipcore-rejected-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2019) is 1757 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 838, but not defined -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: December 30, 2019 Massachusetts Institute of Technology 6 June 28, 2019 8 A Session Initiation Protocol (SIP) Response Code for Rejected Calls 9 draft-ietf-sipcore-rejected-09 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. No one will deliver, and thus no one 16 will answer, the call. As a 6xx code, the caller will be aware that 17 future attempts to contact the same User Agent Server will likely 18 fail. The initial use case driving the need for the 608 response 19 code is when the intermediary is an analytics engine. In this case, 20 the rejection is by a machine or other process. This contrasts with 21 the 607 (Unwanted) SIP response code, which a human at the target 22 User Agent Server indicated the user did not want the call. In some 23 jurisdictions this distinction is important. This document also 24 defines the use of the Call-Info header field in 608 responses to 25 enable rejected callers to contact entities that blocked their calls 26 in error. This provides a remediation mechanism for legal callers 27 that find their calls blocked. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 30, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8 67 3.2. JWS Construction . . . . . . . . . . . . . . . . . . . . 9 68 3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 9 69 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 9 70 3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9 71 3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9 72 3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 10 73 3.5. Announcement Requirements . . . . . . . . . . . . . . . . 11 74 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 12 76 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15 77 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 16 78 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 18 81 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 18 82 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19 83 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 19 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 88 8.2. Informative References . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 The IETF has been addressing numerous issues surrounding how to 94 handle unwanted and, depending on the jurisdiction, illegal calls 95 [RFC5039]. STIR [RFC7340] and SHAKEN [SHAKEN] address the 96 cryptographic signing and attestation, respectively, of signaling to 97 ensure the integrity and authenticity of the asserted caller 98 identity. 100 This document describes a new Session Initiation Protocol (SIP) 101 [RFC3261] response code, 608, which allows calling parties to learn 102 that an intermediary rejected their call. As described below, we 103 need a distinct indicator to differentiate between a user rejection 104 and an intermediary's rejection of a call. In some jurisdictions, 105 service providers may not be permitted to block calls, even if 106 unwanted by the user, unless there is an explicit user request. 107 Moreover, users may misidentify the nature of a caller. 109 For example, a legitimate caller may call a user who finds the call 110 to be unwanted. However, instead of marking the call as unwanted, 111 the user may mark the call as illegal. With that information, an 112 analytics engine may determine to block all calls from that source. 113 However, in some jurisdictions blocking calls from that source for 114 other users may not be legal. Likewise, one can envision 115 jurisdictions that allow an operator to block such calls, but only if 116 there is a remediation mechanism in place to address false positives. 118 Some call blocking services may return responses such as 604 (Does 119 Not Exist Anywhere). This might be a strategy to try to get a 120 destination's address removed from a calling database. However, 121 other network elements might also interpret this to mean the user 122 truly does not exist, which might result in the user not being able 123 to receive calls from anyone, even if they wanted to receive the 124 calls. In many jurisdictions, providing such false signaling is also 125 illegal. 127 The 608 response code addresses this need of remediating falsely 128 blocked calls. Specifically, this code informs the SIP User Agent 129 Client (UAC) that an intermediary blocked the call and provides a 130 redress mechanism that allows callers to contact the operator of the 131 intermediary. 133 In the current call handling ecosystem, users can explicitly reject a 134 call or later mark a call as being unwanted by issuing a 607 SIP 135 response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the 136 operation of the 607 SIP response code. The User Agent Server (UAS) 137 indicates the call was unwanted. As [RFC8197] explains, not only 138 does the called party desire to reject that call, they can let their 139 proxy know that they consider future calls from that source unwanted. 140 Upon receipt of the 607 response from the UAS, the proxy may send 141 unwanted call indicators, such as the value of the From header field 142 and other information elements, to a call analytics engine. For 143 various reasons described in [RFC8197], if a network operator 144 receives multiple reports of unwanted calls, that may indicate that 145 the entity placing the calls is likely to be a source of unwanted 146 calls for many people. As such, other customers of the service 147 provider may want the service provider to automatically reject calls 148 on their behalf. 150 There is another value of the 607 rejection code. Presuming the 151 proxy forwards the response code to the User Agent Client (UAC), the 152 calling UAC or intervening proxies will also learn the user is not 153 interested in receiving calls from that sender. 155 +-----------+ 156 | Call | 157 | Analytics | 158 | Engine | 159 +-----------+ 160 ^ | (likely not SIP) 161 | v 162 +-----------+ 163 +-----+ 607 | Called | 607 +-----+ 164 | UAC | <--------- | Party | <-------- | UAS | 165 +-----+ | Proxy | +-----+ 166 +-----------+ 168 Figure 1: Unwanted (607) Call Flow 170 For calls rejected with a 607 from a legitimate caller, receiving a 171 607 response code can inform the caller to stop attempting to call 172 the user. Moreover, if a legitimate caller believes the user is 173 rejecting their calls in error, they can use other channels to 174 contact the user. For example, if a pharmacy calls a user to let 175 them know their prescription is available for pickup and the user 176 mistakenly thinks the call is unwanted and issues a 607 response 177 code, the pharmacy, having an existing relationship with the 178 customer, can send the user an email or push a note to the pharmacist 179 to ask the customer to consider not rejecting their calls in the 180 future. 182 Many systems that allow the user to mark the call unwanted (e.g., 183 with the 607 response code) also allow the user to change their mind 184 and unmark such calls. This mechanism is relatively easy to 185 implement as the user usually has a direct relationship with the 186 service provider that is blocking calls. 188 However, things become more complicated if an intermediary, such as a 189 third-party provider of call management services that classifies 190 calls based on the relative likelihood that the call is unwanted, 191 misidentifies the call as unwanted. Figure 3 shows this case. Note 192 that the UAS typically does not receive an INVITE since the called 193 party proxy rejects the call on behalf of the user. In this 194 situation, it would be beneficial for the caller to learn who 195 rejected the call, so they can correct the misidentification. 197 +--------+ +-----------+ 198 | Called | | Call | 199 +-----+ | Party | | Analytics | +-----+ 200 | UAC | | Proxy | | Engine | | UAS | 201 +-----+ +--------+ +-----------+ +-----+ 202 | INVITE | | | 203 | --------------> | Is call OK? | | 204 | |------------------->| | 205 | | | | 206 | | Yes | | 207 | |<-------------------| | 208 | | | | 209 | | INVITE | | 210 | | ------------------------------> | 211 | | | | 212 | | | 607 | 213 | | <------------------------------ | 214 | | | | 215 | | Unwanted call | | 216 | 607 | -----------------> | | 217 | <-------------- | indicators | | 218 | | | | 220 Figure 2: Unwanted (607) Ladder Diagram 221 +-----------+ 222 | Call | 223 | Analytics | 224 | Engine | 225 +-----------+ 226 ^ | (likely not SIP) 227 | v 228 +-----------+ 229 +-----+ 608 | Called | +-----+ 230 | UAC | <--------- | Party | | UAS | 231 +-----+ | Proxy | +-----+ 232 +-----------+ 234 Figure 3: Rejected (608) Call Flow 236 In this situation, one might consider to have the intermediary use 237 the 607 response code. 607 indicates to the caller the subscriber 238 does not want the call. However, [RFC8197] specifies that one of the 239 uses of 607 is to inform analytics engines that a user (human) has 240 rejected a call. The problem here is that network elements 241 downstream from the intermediary might interpret the 607 as coming 242 from a user (human) who has marked the call as unwanted, as opposed 243 to coming from an algorithm using statistics or machine learning to 244 reject the call. An algorithm can be vulnerable to the base rate 245 fallacy [BaseRate] rejecting the call. In other words, those 246 downstream entities should not rely on another entity 'deciding' the 247 call is unwanted. By distinguishing between a (human) user rejection 248 and an intermediary engine's statistical rejection, a downstream 249 network element that sees a 607 response code can weigh it as a human 250 rejection in its call analytics, versus deciding whether to consider 251 a 608 at all, and if so, weighing it appropriately. 253 It is useful for blocked callers to have a redress mechanism. One 254 can imagine that some jurisdictions will require it. However, we 255 must be mindful that most of the calls that intermediaries block 256 will, in fact, be illegal and eligible for blocking. Thus, providing 257 alternate contact information for a user would be counterproductive 258 to protecting that user from illegal communications. This is another 259 reason we do not propose to simply allow alternate contact 260 information in a 607 response message. 262 Why do we not use the same mechanism an analytics service provider 263 offers their customers? Specifically, why not have the analytics 264 service provider allow the called party to correct a call blocked in 265 error? The reason is while there is an existing relationship between 266 the customer (called party) and the analytics service provider, it is 267 unlikely there is a relationship between the caller and the analytics 268 service provider. Moreover, there are numerous call blocking 269 providers in the ecosystem. Therefore, we need a mechanism for 270 indicating an intermediary rejected a call that also provides contact 271 information for the operator of that intermediary, without exposing 272 the target user's contact information. 274 The protocol described in this document uses existing SIP protocol 275 mechanisms for specifying the redress mechanism. In the Call-Info 276 header passed back to the UAC, we send additional information 277 specifying a redress address. We choose to encode the redress 278 address using jCard [RFC7095]. As we will see later in this 279 document, this information needs to have its own, application-layer 280 integrity protection. Thus, we use jCard rather than vCard [RFC6350] 281 as we have a marshaling mechanism for creating a JavaScript Object 282 Notation (JSON) [RFC8259] object, such as a jCard, and a standard 283 integrity format for such an object, namely JSON Web Signature (JWS) 284 [RFC7515]. The SIP community is familiar with this concept as it is 285 the mechanism used by STIR [RFC8224]. 287 Integrity protecting the jCard with a cryptographic signature might 288 seem unnecessary at first, but it is essential to preventing 289 potential network attacks. Section 6 describes the attack and why we 290 sign the jCard in more detail. 292 2. Terminology 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 296 "OPTIONAL" in this document are to be interpreted as described in BCP 297 14 [RFC2119][RFC8174] when, and only when, they appear in all 298 capitals, as shown here. 300 3. Protocol Operation 302 This section uses the term 'intermediary' to mean the entity that 303 acts as a SIP User Agent Server (UAS) on behalf of the user in the 304 network, as opposed to the user's UAS (usually, but not necessarily, 305 their phone). The intermediary could be a back-to-back user agent 306 (B2BUA) or a SIP Proxy. 308 Figure 4 shows an overview of the call flow for a rejected call. 310 +--------+ +-----------+ 311 | Called | | Call | 312 +-----+ | Party | | Analytics | +-----+ 313 | UAC | | Proxy | | Engine | | UAS | 314 +-----+ +--------+ +-----------+ +-----+ 315 | INVITE | | | 316 | --------------> | Information from | | 317 | | -----------------> | | 318 | | INVITE | | 319 | | Reject | | 320 | 608 | <----------------- | | 321 | <-------------- | call | | 322 | | | | 324 Figure 4: Rejected (608) Ladder Diagram 326 3.1. Intermediary Operation 328 An intermediary MAY issue the 608 response code in a failure response 329 for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP 330 [RFC3261] request to indicate that an intermediary rejected the 331 offered communication as unwanted by the user. An intermediary MAY 332 issue the 608 as the value of the "cause" parameter of a SIP reason- 333 value in a Reason header field [RFC3326]. 335 If an intermediary issues a 608 code and there are no indicators the 336 calling party will use the contents of the Call-Info header field for 337 malicious purposes (see Section 6), the intermediary MUST include a 338 Call-Info header field in the response. 340 If there is a Call-Info header field, it MUST have the 'purpose' 341 parameter of 'jwscard'. The value of the Call-Info header field MUST 342 refer to a valid JSON Web Signature (JWS [RFC7515]) encoding of a 343 jCard [RFC7095] object. The following section describes the 344 construction of the JWS. 346 Proxies need to be mindful that a downstream intermediary may reject 347 the attempt with a 608 while other paths may still be in progress. 348 In this situation, the requirements stated in Section 16.7 of 349 [RFC3261] apply. Specifically, the proxy should cancel pending 350 transactions and must not create any new branches. Note this is not 351 a new requirement but simply pointing out the existing 6xx protocol 352 mechanism in SIP. 354 3.2. JWS Construction 356 The intermediary constructs the JWS of the jCard as follows. 358 3.2.1. JOSE Header 360 The Javascript Object Signing and Encryption (JOSE) header MUST 361 include the typ, alg, and x5u parameters from JWS [RFC7515]. The typ 362 parameter MUST have the value "vcard+json". Implementations MUST 363 support ES256 as JSON Web Algorithms (JWA [RFC7518]) defines it, and 364 MAY support other registered signature algorithms. Finally, the x5u 365 parameter MUST be a URI that resolves to the public key certificate 366 corresponding to the key used to digitally sign the JWS. 368 3.2.2. JWT Payload 370 The payload contains two JSON values. The first JSON Web Token (JWT) 371 claim that MUST be present is the iat (issued at) claim [RFC7519]. 372 The "iat" MUST be set to the date and time of the issuance of the 608 373 response. This mandatory component protects the response from replay 374 attacks. 376 The second JWT claim that MUST be present is the "jcard" claim. The 377 value of the jcard [RFC7095] claim is a JSON array conforming to the 378 JSON jCard data format defined in RFC7095 Section 5.3 describes the 379 registration. In the construction of the jcard claim, the "jcard" 380 MUST include at least one of the URL, EMAIL, TEL, or ADR properties. 381 UACs supporting this specification MUST be prepared to receive a full 382 jCard. Call originators (at the UAC) can use the information 383 returned by the jCard to contact the intermediary that rejected the 384 call to appeal the intermediary's blocking of the call attempt. What 385 the intermediary does if the blocked caller contacts the intermediary 386 is outside the scope of this document. 388 3.2.3. JWS Signature 390 JWS [RFC7515] specifies the procedure for calculating the signature 391 over the jCard JWT. Section 4 of this document has a detailed 392 example on constructing the JWS, including the signature. 394 3.3. UAC Operation 396 A UAC conforming to this specification MUST include the sip.608 397 feature capability indicator in the Feature-Caps header field of the 398 INVITE request. 400 Upon receiving a 608 response, UACs perform normal SIP processing for 401 6xx responses. 403 As for the disposition of the jCard itself, the UAC MUST check the 404 "iat" claim in the JWT. As noted in Section 3.2.3, we are concerned 405 about replay attacks. Therefore, the UAC MUST reject jCards that 406 come with an expired "iat". The definition of "expired" is a matter 407 of local policy. A reasonable value would be on the order of a 408 minute due to clock drift and the possibility of the playing of an 409 audio announcement before the delivery of the 608 response. 411 3.4. Legacy Interoperation 413 If the UAC indicates support for 608 and the intermediary issues a 414 608, life is good, as the UAC will receive all the information it 415 needs to remediate an erroneous block by an intermediary. However, 416 what if the UAC does not understand 608? For example, how can we 417 support callers from a legacy, non-SIP public switched network 418 connecting to the SIP network via a media gateway? 420 We address this situation by having the first network element that 421 conforms with this specification play an announcement in the media. 422 See Section 3.5 for requirements on the announcement. The simple 423 rule is a network element that inserts the sip.608 feature capability 424 MUST be able to convey at a minimum how to contact the operator of 425 the intermediary that rejected the call attempt. 427 The degenerate case is the intermediary is the only element that 428 understands the semantics of the 608 response code. Obviously, any 429 SIP device will understand that a 608 response code is a 6xx error. 430 However, there are no other elements in the call path that understand 431 the meaning of the value of the Call-Info header field. The 432 intermediary knows this is the case as the INVITE request will not 433 have the sip.608 feature capability. In this case, one can consider 434 the intermediary to be the element 'inserting' a virtual sip.608 435 feature capability. If the caveats described in Section 3.5 and 436 Section 6 do not hold, the intermediary MUST play the announcement. 438 Now we take the case where a network element that understands the 608 439 response code receives an INVITE for further processing. A network 440 element conforming with this specification MUST insert the sip.608 441 feature capability, per the behaviors described in Section 4.2 of 442 [RFC6809]. 444 Do note that even if a network element plays an announcement 445 describing the contents of the 608 response message, the network 446 element MUST forward the 608 response code message as the final 447 response to the INVITE. 449 One aspect of using a feature capability is that only the network 450 elements that will either consume (UAC) or play an announcement 451 (media gateway, session border controller (SBC [RFC7092]), or proxy) 452 need to understand the sip.608 feature capability. If the other 453 network elements conform to Section 16.6 of [RFC3261], they will pass 454 header fields such as "Feature-Caps: *;+sip.608" unmodified and 455 without need for upgrade. 457 Because the ultimate disposition of the call attempt will be a 458 600-class response, the network element conveying the announcement in 459 the legacy direction MUST use the 183 Session Progress response to 460 establish the media session. Because of the small chance the UAC is 461 an extremely old legacy device and is using UDP, the UAC MUST include 462 support for 100Rel [RFC3262] in its INVITE and the network element 463 conveying the announcement MUST Require 100Rel in the 183 and the UAC 464 MUST issue a PRACK to which the network element MUST respond 200 OK 465 PRACK. 467 3.5. Announcement Requirements 469 There are a few requirements on the element that handles the 470 announcement for legacy interoperation. 472 As noted above, the element that inserts the sip.608 feature 473 capability is responsible for conveying the information referenced by 474 the Call-Info header field in the 608 response message. However, 475 this specification does not mandate how to convey that information. 477 Let us take the case where a telecommunications service provider 478 controls the element inserting the sip.608 feature capability. It 479 would be reasonable to expect the service provider would play an 480 announcement in the media path towards the UAC (caller). It is 481 important to note the network element should be mindful of the media 482 type requested by the UAC as it formulates the announcement. For 483 example, it would make sense for an INVITE that only indicated audio 484 codecs in the Session Description Protocol (SDP) [RFC4566] to result 485 in an audio announcement. Likewise, if the INVITE only indicated a 486 real-time text codec [RFC4103] and the network element can render the 487 information in the requested media format, the network element should 488 send the information in a text format. 490 It is also possible for the network element inserting the sip.608 491 feature capability to be under the control of the same entity that 492 controls the UAC. For example, a large call center might have legacy 493 UACs, but have a modern outbound calling proxy that understands the 494 full semantics of the 608 response code. In this case, it is enough 495 for the outbound calling proxy to digest the Call-Info information 496 and handle the information digitally, rather than 'transcoding' the 497 Call-Info information for presentation to the caller. 499 4. Examples 501 These examples are not normative, do not include all protocol 502 elements, and may have errors. Review the protocol documents for 503 actual syntax and semantics of the protocol elements. 505 4.1. Full Exchange 507 Given an INVITE, shamelessly taken from [SHAKEN], with the line 508 breaks in the Identity header field for display purposes only: 510 INVITE sip:+12155550113@tel.one.example.net SIP/2.0 511 Max-Forwards: 69 512 Contact: 513 To: 514 From: "Alice" ;tag=614bdb40 515 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 516 P-Asserted-Identity: "Alice", 517 518 CSeq: 2 INVITE 519 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, 520 MESSAGE, OPTIONS 521 Content-Type: application/sdp 522 Date: Tue, 16 Aug 2016 19:23:38 GMT 523 Feature-Caps: *;+sip.608 524 Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V 525 uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ 526 hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx 527 Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN 528 DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU 529 tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info= 530 ;alg=ES256 531 Content-Length: 153 533 v=0 534 o=- 13103070023943130 1 IN IP6 2001:db8::177 535 c=IN IP6 2001:db8::177 536 t=0 0 537 m=audio 54242 RTP/AVP 0 538 a=sendrecv 540 An intermediary could reply: 542 SIP/2.0 608 Rejected 543 Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1 544 From: "Alice" ;tag=614bdb40 545 To: 546 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 547 CSeq: 2 INVITE 548 Call-Info: ;purpose=jwscard 550 The location https://block.example.net/complaint-jws resolves to a 551 JWS. One would construct the JWS as follows. 553 The JWS header of this example jCard could be: 555 { "alg":"ES256", 556 "typ":"vcard+json", 557 "x5u":"https://certs.example.net/reject_key.cer" 558 } 560 Now, let us construct a minimal jCard. For this example, the jCard 561 refers the caller to an email address, 562 remediation@blocker.example.net: 564 ["vcard", 565 [ 566 ["version", {}, "text", "4.0"], 567 ["fn", {}, "text", "Robocall Adjudication"], 568 ["email", {"type":"work"}, 569 "text", "remediation@blocker.example.net"] 570 ] 571 ] 573 With this jCard, we can now construct the JWT: 575 { 576 "iat":1546008698, 577 "jcard":["vcard", 578 [ 579 ["version", {}, "text", "4.0"], 580 ["fn", {}, "text", "Robocall Adjudication"], 581 ["email", {"type":"work"}, 582 "text", "remediation@blocker.example.net"] 583 ] 584 ] 585 } 586 To calculate the signature, we need to encode the JSON Object Signing 587 and Encryption (JOSE) header and JWT into base64url. As an 588 implementation note, one can trim whitespace in the JSON objects to 589 save a few bytes. UACs MUST be prepared to receive pretty-printed, 590 compact, or bizarrely formatted JSON. For the purposes of this 591 example, we leave the objects with pretty whitespace. Speaking of 592 pretty vs. machine formatting, these examples have line breaks in the 593 base64url encodings for ease of publication in the RFC format. The 594 specification of base64url allows for these line breaks and the 595 decoded text works just fine. However, those extra line break octets 596 would affect the calculation of the signature. Implementations MUST 597 NOT insert line breaks into the base64url encodings of the JOSE 598 header or JWT. This also means UACs MUST be prepared to receive 599 arbitrarily long octet streams from the URI referenced by the Call- 600 Info SIP header. 602 base64url of JOSE header: 603 eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczov 604 L2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0= 606 base64url of JWT: 607 eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7 608 fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRp 609 Y2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRp 610 YXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 612 In this case, the object to sign (remembering this is just a single, 613 long line; the line breaks are for ease of review but do not appear 614 in the actual object) is as follows: 616 eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJk 617 K2pzb24iLCJ4NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9r 618 ZXkuY2VyIn0.eyJpYXQiOjE1NDYwMDg2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2 619 ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJdLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2Nh 620 bGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFpbCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0 621 IiwicmVtZWRpYXRpb25AYmxvY2tlci5leGFtcGxlLm5ldCJdXV19 623 We use the following X.509 PKCS #8-encoded ECDSA key, also 624 shamelessly taken from [SHAKEN]), as an example key for signing the 625 hash of the above text. Do NOT use this key in real life! It is for 626 example purposes only. At the very least, we would strongly 627 recommend encrypting the key at rest. 629 -----BEGIN PRIVATE KEY----- 630 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy 631 qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW 632 ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh 633 -----END PRIVATE KEY----- 635 -----BEGIN PUBLIC KEY----- 636 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 637 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 638 -----END PUBLIC KEY----- 640 The resulting JWS, using the above key on the above object, renders 641 the following ECDSA P-256 SHA-256 digital signature. 643 7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6g9AmL 644 5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag 646 Thus, the JWS stored at https://blocker.example.net/complaints-jws, 647 would contain: 649 eyJhbGciOiJFUzI1NiIsInR5cCI6InZjYXJkK2pzb24iLCJ4NXUiOiJodHRwczovL 650 2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0.eyJpYXQiOjE1NDYwMD 651 g2OTgsImpjYXJkIjpbInZjYXJkIixbWyJ2ZXJzaW9uIix7fSwidGV4dCIsIjQuMCJ 652 dLFsiZm4iLHt9LCJ0ZXh0IiwiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIl0sWyJlbWFp 653 bCIseyJ0eXBlIjoid29yayJ9LCJ0ZXh0IiwicmVtZWRpYXRpb25AYmxvY2tlci5le 654 GFtcGxlLm5ldCJdXV19.7uz2SADRvPFOQOO_UgF2ZTUjPlDTegtPrYB04UHBMwBD6 655 g9AmL5harLJdTKDSTtH-LOV1jwJaGRUOUJiwP27ag 657 4.2. Web Site jCard 659 For an intermediary that provides a Web site for adjudication, the 660 jCard could contain the following. Note we do not show the 661 calculation of the JWS; the URI reference in the Call-Info header 662 field would be to the JWS of the signed jCard. 664 ["vcard", 665 [ 666 ["version", {}, "text", "4.0"], 667 ["fn", {}, "text", "Robocall Adjudication"], 668 ["url", {"type":"work"}, 669 "text", "https://blocker.example.net/adjudication-form"] 670 ] 671 ] 673 4.3. Multi-modal jCard 675 For an intermediary that provides a telephone number and a postal 676 address, the jCard could contain the following. Note we do not show 677 the calculation of the JWS; the URI reference in the Call-Info header 678 field would be to the JWS of the signed jCard. 680 ["vcard", 681 [ 682 ["version", {}, "text", "4.0"], 683 ["fn", {}, "text", "Robocall Adjudication"], 684 ["adr", {"type":"work"}, "text", 685 ["Argument Clinic", 686 "12 Main St","Anytown","AP","000000","Somecountry"] 687 ] 688 ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"] 689 ] 690 ] 692 Note that it is up to the UAC to decide which jCard contact modality, 693 if any, it will use. 695 4.4. Legacy Interoperability 697 Figure 5 depicts a call flow illustrating legacy interoperability. 698 In this non-normative example, we see a UAC that does not support the 699 full semantics for 608. However, there is an SBC that does support 700 608. Per [RFC6809], the SBC can insert "*;+sip.608" into the 701 Feature-Caps header field for the INVITE. When the intermediary, 702 labeled "Called Party Proxy" in the figure, rejects the call, it 703 knows it can simply perform the processing described in this 704 document. Since the intermediary saw the sip.608 feature capability, 705 it knows it does not need to send any media describing whom to 706 contact in the event of an erroneous rejection. For illustrative 707 purposes, the figure shows generic SIP Proxies in the flow. Their 708 presence or absence or the number of proxies is not relevant to the 709 operation of the protocol. They are in the figure to show that 710 proxies that do not understand the sip.608 feature capability can 711 still participate in a network offering 608 services. 713 +---------+ 714 | Call | 715 |Analytics| 716 | Engine | 717 +--+--+---+ 718 ^ | 719 | | 720 | v 721 +-+--+-+ 722 +---+ +-----+ +---+ +-----+ +-----+ |Called| 723 |UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party | 724 +---+ +-----+ +---+ +-----+ +-----+ |Proxy | 725 | | +------+ 726 | INVITE | | 727 |------------------>| | 728 | | INVITE | 729 | |------------------------------>| 730 | | Feature-Caps: *;+sip.608 | 731 | | | 732 | | 608 Rejected | 733 | |<------------------------------| 734 | 183 | Call-Info: <...> | 735 |<------------------| [path for Call-Info elided | 736 | SDP for media | for illustration purposes]| 737 | | | 738 | PRACK | | 739 |------------------>| | 740 | | | 741 | 200 OK PRACK | | 742 |<------------------| | 743 | | | 744 |<== Announcement ==| | 745 | | | 746 | 608 Rejected | | 747 |<------------------| | 748 | Call-Info: <...> | | 749 | | | 751 Figure 5: Legacy Operation 753 When the SBC receives the 608 response code, it correlates that with 754 the original INVITE from the UAC. The SBC remembers that it inserted 755 the sip.608 feature capability, which means it is responsible for 756 somehow alerting the UAC the call failed and whom to contact. At 757 this point the SBC can play a prompt, either natively or through a 758 mechanism such as NETANN [RFC4240], that sends the relevant 759 information in the appropriate media to the UAC. Since this is a 760 potentially long transaction and there is a chance the UAC is using 761 an unreliable transport protocol, the UAC will have indicated support 762 for provisional responses, the SBC will indicate it requires a PRACK 763 from the UAC in the 183 response, the UAC will provide the PRACK, and 764 the SBC will acknowledge receipt of the PRACK before playing the 765 announcement. 767 As an example, the SBC could extract the FN and TEL jCard fields and 768 play something like a special information tone (see Telcordia SR-2275 769 [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section 770 7), followed by "Your call has been rejected by ...", followed by a 771 text-to-speech translation of the FN text, followed by "You can reach 772 them on", followed by a text-to-speech translation of the telephone 773 number in the TEL field. 775 Note the SBC also still sends the full 608 response code, including 776 the Call-Info header, towards the UAC. 778 5. IANA Considerations 780 5.1. SIP Response Code 782 This document defines a new SIP response code, 608 in the "Response 783 Codes" subregistry of the "Session Initiation Protocol (SIP) 784 Parameters" registry defined in [RFC3261]. 786 Response code: 608 788 Description: Rejected 790 Reference: [RFCXXXX] 792 5.2. SIP Feature-Capability Indicator 794 This document defines the feature capability sip.608 in the "SIP 795 Feature-Capability Indicator Registration Tree" registry defined in 796 [RFC6809]. 798 Name: sip.608 800 Description: This feature capability indicator, when included in a 801 Feature-Caps header field of an INVITE request, indicates that the 802 entity associated with the indicator will be responsible for 803 indicating to the caller any information contained in the 608 SIP 804 response code, specifically the value referenced by the Call-Info 805 header. 807 Reference: [RFCXXXX] 809 5.3. JSON Web Token Claim 811 This document defines the new JSON Web Token claim in the "JSON Web 812 Token Claims" sub-registry created by [RFC7519]. Section 3.2.2 813 defines the syntax. The required information is: 815 Claim Name: jcard 817 Claim Description: jCard data 819 Change Controller: IESG 821 Reference: [RFCXXXX], [RFC7095] 823 5.4. Call-Info Purpose 825 This document defines the new predefined value "jwscard" for the 826 "purpose" header field parameter of the Call-Info header field. This 827 modifies the "Header Field Parameters and Parameter Values" 828 subregistry of the "Session Initiation Protocol (SIP) Parameters" 829 registry by adding this RFC as a reference to the line for the header 830 field "Call-Info" and parameter name "purpose": 832 Header Field: Call-Info 834 Parameter Name: purpose 836 Predefined Values: Yes 838 Reference: [RFCXXXX] 840 6. Security Considerations 842 Intermediary operators need to be mindful to whom they are sending 843 the 608 response. The intermediary could be rejecting a truly 844 malicious caller. This raises two issues. The first is the caller, 845 now alerted an intermediary is automatically rejecting their call 846 attempts, may change their call behavior to defeat call blocking 847 systems. The second, and more significant risk, is that by providing 848 a contact in the Call-Info header field, the intermediary may be 849 giving the malicious caller a vector for attack. In other words, the 850 intermediary will be publishing an address that a malicious actor may 851 use to launch an attack on the intermediary. Because of this, 852 intermediary operators may wish to configure their response to only 853 include a Call-Info header field for INVITE or other signed 854 initiating methods and that pass validation by STIR [RFC8224]. 856 Another risk is as follows. Consider an attacker that floods a proxy 857 that supports the sip.608 feature. However, the SDP in the INVITE 858 request refers to a victim device. Moreover, the attacker somehow 859 knows there is a 608-aware gateway connecting to the victim who is on 860 a segment that lacks the sip.608 feature capability. Because the 861 mechanism described here can result in sending an audio file to the 862 target of the SDP, an attacker could use the mechanism described by 863 this document as an amplification attack, given a SIP INVITE can be 864 under 1 kilobyte and an audio file can be hundreds of kilobytes. One 865 remediation for this is for devices that insert a sip.608 feature 866 capability to only transmit media to what is highly likely to be the 867 actual source of the call attempt. A method for this is to only play 868 media in response to a STIR-signed INVITE that passes validation. 869 Beyond requiring a valid STIR signature on the INVITE, the 870 intermediary can also use remediation procedures such as doing the 871 connectivity checks specified by Interactive Connectivity 872 Establishment [RFC8445]. If the target did not request the media, 873 the check will fail. 875 Yet another risk is a malicious intermediary that generates a 876 malicious 608 response with a jCard referring to a malicious agent. 877 For example, the recipient of a 608 may receive a TEL URI in the 878 vCard. When the recipient calls that address, the malicious agent 879 could ask for personally identifying information. However, instead 880 of using that information to verify the recipient's identity, they 881 are phishing the information for nefarious ends. A similar scenario 882 can unfold if the malicious agent inserts a URI that points to a 883 phishing or other site. As such, we strongly recommend the recipient 884 validates to whom they are communicating with if asking to adjudicate 885 an erroneously rejected call attempt. Since we may also be concerned 886 about intermediate nodes modifying contact information, we can 887 address both issues with a single solution. The remediation is to 888 require the intermediary to sign the jCard. Signing the jCard 889 provides integrity protection. In addition, one can imagine 890 mechanisms such as used by SHAKEN [SHAKEN]. 892 Similarly, one can imagine an adverse agent that maliciously spoofs a 893 608 response with a victim's contact address to many active callers, 894 who may then all send redress requests to the specified address (the 895 basis for a denial-of-service attack). The process would occur as 896 follows: (1) a malicious agent senses INVITE requests from a variety 897 of UACs and (2) spoofs 608 responses with an unsigned redress address 898 before the intended receivers can respond, causing (3) the UACs to 899 all contact the redress address at once. The jCard encoding allows 900 the UAC to verify the blocking intermediary's identity before 901 contacting the redress address. Specifically, because the sender 902 signs the jCard, we can cryptographically trace the sender of the 903 jCard. Given the protocol machinery of having a signature, one can 904 apply local policy to decide whether to believe the sender of the 905 jCard represents the owner of the contact information found in the 906 jCard. This guards against a malicious agent spoofing 608 responses. 908 Specifically, one could use policies around signing certificate 909 issuance as a mechanism for traceback to the entity issuing the 910 jCard. One check could be verifying the identity of the subject of 911 the certificate relates to the To header field of the initial SIP 912 request, similar to validating the intermediary was vouching for the 913 From header field of a SIP request with that identity. Note that we 914 are only protecting against a malicious intermediary and not a hidden 915 intermediary attack (formerly known as a "man in the middle attack"). 916 Thus, we only need to ensure the signature is fresh, which is why we 917 include "iat". For most implementations, we assume that the 918 intermediary has a single set of contact points and will generate the 919 jCard on demand. As such, there is no need to directly correlate 920 HTTPS fetches to specific calls. However, since the intermediary is 921 in control of the jCard and Call-Info response, an intermediary may 922 choose to encode per-call information in the URI returned in a given 923 608 response. However, if the intermediary does go that route, the 924 intermediary MUST use a non-deterministic URI reference mechanism and 925 be prepared to return dummy responses to URI requests referencing 926 calls that do not exist so that attackers attempting to glean call 927 metadata by guessing URI's (and thus calls) will not get any 928 actionable information from the HTTPS GET. 930 Since the decision of whether to include Call-Info in the 608 931 response is a matter of policy, one thing to consider is whether a 932 legitimate caller can ascertain whom to contact without including 933 such information in the 608. For example, in some jurisdictions, if 934 only the terminating service provider can be the intermediary, the 935 caller can look up who the terminating service provider is based on 936 the routing information for the dialed number. Thus, the Call-Info 937 jCard could be redundant information. However, the factors going 938 into a particular service provider's or jurisdiction's choice of 939 whether to include Call-Info is outside the scope of this document. 941 7. Acknowledgements 943 This document liberally lifts from [RFC8197] in its text and 944 structure. However, the mechanism and purpose of 608 is quite 945 different than 607. Any errors are the current editor's and not the 946 editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ 947 Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on 948 improving the draft. Tolga's suggestion to provide a mechanism for 949 legacy interoperability served to expand the draft by 50%. In 950 addition, Tolga came up with the jCard attack. Finally, Christer 951 Holmberg as always provided a close reading and fixed a SIP feature 952 capability bug found by Yehoshua Gev. 954 Of course, we appreciated the close read and five pages of comments 955 from our estimable Area Director, Adam Roach. In addition, we 956 received valuable comments during IETF Last Call and JWT review from 957 Ines Robles, Mike Jones, and Brian Campbell and IESG review from 958 Alissa Cooper, Eric Vyncke, Alexey Melnikov, Benjamin Kaduk, Barry 959 Leiba, and with most glee, Warren Kumari. 961 Finally, Bhavik Nagda provided clarifying edits as well and more 962 especially wrote and tested an implementation of the 608 response 963 code in Kamailio. Code is available at . Grace Chuan from MIT regenerated and 965 verified the JWT while working at the FCC. 967 8. References 969 8.1. Normative References 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, 973 DOI 10.17487/RFC2119, March 1997, 974 . 976 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 977 A., Peterson, J., Sparks, R., Handley, M., and E. 978 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 979 DOI 10.17487/RFC3261, June 2002, 980 . 982 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 983 Provisional Responses in Session Initiation Protocol 984 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 985 . 987 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 988 Header Field for the Session Initiation Protocol (SIP)", 989 RFC 3326, DOI 10.17487/RFC3326, December 2002, 990 . 992 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 993 Indicate Support of Features and Capabilities in the 994 Session Initiation Protocol (SIP)", RFC 6809, 995 DOI 10.17487/RFC6809, November 2012, 996 . 998 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 999 DOI 10.17487/RFC7095, January 2014, 1000 . 1002 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1003 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1004 2015, . 1006 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 1007 DOI 10.17487/RFC7518, May 2015, 1008 . 1010 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1011 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1012 . 1014 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1015 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1016 May 2017, . 1018 8.2. Informative References 1020 [BaseRate] 1021 Bar-Hillel, M., "The Base-Rate Fallacy in Probability 1022 Judgements", 4 1977, < 1023 https://apps.dtic.mil/docs/citations/ADA045772>. 1025 [ITU.E.180.1998] 1026 International Telecommunications Union, "Technical 1027 characteristics of tones for the telephone service", 1028 ITU Recommendation E.180/Q.35, March 1998. 1030 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1031 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1032 . 1034 [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic 1035 Network Media Services with SIP", RFC 4240, 1036 DOI 10.17487/RFC4240, December 2005, 1037 . 1039 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1040 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1041 July 2006, . 1043 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1044 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 1045 January 2008, . 1047 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 1048 DOI 10.17487/RFC6350, August 2011, 1049 . 1051 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1052 Initiation Protocol (SIP) Back-to-Back User Agents", 1053 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1054 . 1056 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1057 Telephone Identity Problem Statement and Requirements", 1058 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1059 . 1061 [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 1062 RFC 8197, DOI 10.17487/RFC8197, July 2017, 1063 . 1065 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1066 "Authenticated Identity Management in the Session 1067 Initiation Protocol (SIP)", RFC 8224, 1068 DOI 10.17487/RFC8224, February 2018, 1069 . 1071 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1072 Interchange Format", STD 90, RFC 8259, 1073 DOI 10.17487/RFC8259, December 2017, 1074 . 1076 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1077 Connectivity Establishment (ICE): A Protocol for Network 1078 Address Translator (NAT) Traversal", RFC 8445, 1079 DOI 10.17487/RFC8445, July 2018, 1080 . 1082 [SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS) 1083 and the SIP Forum, "Signature-based Handling of Asserted 1084 information using toKENs (SHAKEN)", ATIS 1000074, 1 2017, 1085 . 1089 [SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR- 1090 2275, October 2000. 1092 Authors' Addresses 1094 Eric W. Burger 1095 Georgetown University 1096 37th & O St, NW 1097 Washington, DC 20057 1098 USA 1100 Email: eburger@standardstrack.com 1102 Bhavik Nagda 1103 Massachusetts Institute of Technology 1104 77 Massachusetts Avenue 1105 Cambridge, MA 02139 1106 USA 1108 Email: nagdab@gmail.com