idnits 2.17.1 draft-penar-sipcore-ratingprovided-01.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 24, 2020) is 1394 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-penar-sipcore-ratingprovided-01 2 SIPCORE R. Penar 3 Internet-Draft Microsoft 4 Intended Status: Standards Track June 24, 2020 5 Expires: January 01, 2021 7 A Session Initiation Protocol (SIP) Response Code for Call Rating 9 Abstract 11 This document defines the 120 (Rated) Session Initiation Protocol 12 (SIP) response code. This response code enables calling parties to 13 learn an intermediary rated their call attempt. Depending on 14 rating (e.g. Scam), the call may go unanswered. Through a 1xx code, 15 the caller's network may become aware future attempts to contact the 16 same User Agent Server (UAS) will likely go unanswered. The initial 17 use case driving the need for a 120 response code is when the 18 intermediary is an analytics engine. Code 120 (Rated) contrasts with 19 607 (Unwanted) & 608 (Rejected) SIP response codes in which a human 20 at target UAS, or terminating network analytics, indicate the call 21 may not completed. This document also defines use of a Call-Info 22 header field in 120 (Rated) responses to enable negatively rated 23 callers to contact entities that rated their calls in error. This 24 provides a remediation mechanism for legal callers who find their 25 calls going unanswered (not necessarily blocked). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 01, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction 62 2. Terminology 63 3. Protocol Operation 64 3.1. Intermediary Operation 65 3.2. JWS Construction 66 3.2.1. JOSE Header 67 3.2.2. JWT Payload 68 3.2.3. JWS Signature 69 3.3. UAC Operation 70 3.4. Legacy Interoperation 71 3.5. Forking 72 4. Examples 73 4.1. Full Exchange 74 4.2. Web Site jCard 75 4.3. Multi-modal jCard 76 4.4. Legacy Interoperability 77 5. IANA Considerations 78 5.1. SIP Response Code 79 5.2. SIP Feature-Capability Indicator 80 5.3. JSON Web Token Claim 81 5.4. Call-Info Purpose 82 6. Security Considerations 83 7. References 84 7.1. Normative References 85 7.2. Informative References 86 Acknowledgements 87 Authors' Addresses 89 1. Introduction 91 The IETF has been addressing numerous issues surrounding how to 92 handle unwanted and, depending on the jurisdiction, illegal calls 93 [RFC5039]. Secure Telephone Identity Revisited (STIR) [RFC7340] and 94 Signature-based Handling of Asserted information using toKENs 95 (SHAKEN) [SHAKEN] address the cryptographic signing and attestation, 96 respectively, of signaling to ensure the integrity and authenticity 97 of the asserted caller identity. 99 This document describes a new Session Initiation Protocol (SIP) 100 [RFC3261] response code, 120, which allows calling parties to learn 101 an intermediary rated their call. As described below, we need a 102 distinct indicator to signal how a call's rating is being presented 103 to the called party. 105 For example, a legitimate caller may call a user who observes the 106 call is rated poorly, e.g. Scam. Thus, instead of answering the 107 call, the called party simply does not answer the call. 109 The 120 response code addresses this need of remediating incorrectly 110 rated calls. Specifically, this code informs the SIP User Agent 111 Client (UAC) an intermediary rated the call and provides a 112 redress mechanism allowing callers (or their operator) to contact 113 the operator of the intermediary. 115 For calls rated poorly from a legitimate caller, receiving a 116 120 response code can inform the caller to evaluate their calling 117 procedures & patterns. Moreover, if a legitimate caller believes the 118 user is ignoring their calls in error, they can use redress channels 119 to contact the intermediary. For example, a pharmacy calls a user to 120 alert them a prescription is available for pickup and the user 121 mistakenly thinks the call is a scam, the pharmacy has a means of 122 communicating with the intermediary to update the rating to increase 123 chances of the specific pharmacy calls being answered in the future. 125 The scenario is exacerbated when an intermediary, such as 126 a third-party provider of call management services, classifies 127 calls based on the relative likelihood the call is unwanted and 128 misidentifies the call as unwanted. Figure 1 shows this case. 129 Note the UAS typically does receive an INVITE as the called party 130 proxy rates the call on behalf of the user or network. In this 131 situation, it would be beneficial for the caller to learn who 132 rated the call so they can correct any misidentification. 134 +--------+ +-----------+ 135 | Called | | Call | 136 +-----+ | Party | | Analytics | +-----+ 137 | UAC | | Proxy | | Engine | | UAS | 138 +-----+ +--------+ +-----------+ +-----+ 139 | INVITE | | | 140 | --------------> | Is call OK? | | 141 | |------------------->| | 142 | | | | 143 | | Scam | | 144 | |<-------------------| | 145 | 120 | | | 146 | <-------------- | INVITE w/scam likely display | 147 | | ------------------------------> | 148 | | | | 150 Caller cancels, leaves voicemail, or receives no-answer recording. 152 Figure 1: Rated (120) Ladder Diagram 153 It is useful for rated callers to have a redress mechanism. One 154 can imagine some jurisdictions will require it. However, we 155 must be mindful most of the calls intermediaries rate poorly 156 will, in fact, be illegal and should not be answered. 158 Why do we not use the same mechanism an analytics service provider 159 offers their customers? Specifically, why not have the analytics 160 service provider allow a calling party to correct calls rated in 161 error? The reason is while there is an existing relationship 162 between the customer (called party) and the analytics service 163 provider, it is unlikely there is a relationship between the caller 164 and the analytics service provider. Moreover, there are numerous 165 call rating providers in the ecosystem. Therefore, we need a 166 mechanism for indicating an intermediary rated a call that also 167 provides contact information for the operator of the intermediary 168 without exposing the target user's contact information. 170 The protocol described in this document uses existing SIP protocol 171 mechanisms for specifying the rating and redress mechanism. In the 172 Call-Info header field passed back to the UAC, we send additional 173 information specifying rating and redress address. We choose to 174 encode redress address using jCard [RFC7095]. As we will see later 175 in this document, this information needs to have its own 176 application-layer integrity protection. Thus, we use jCard rather 177 than vCard [RFC6350], as we have a marshaling mechanism for creating 178 a JavaScript Object Notation (JSON) [RFC8259] object, such as a jCard 179 ,and a standard integrity format for such an object, namely, JSON Web 180 Signature (JWS) [RFC7515]. The SIP community is familiar with this 181 concept as it is the mechanism used by STIR [RFC8224]. 183 Integrity protecting the jCard with a cryptographic signature might 184 seem unnecessary at first, but it is essential to preventing 185 potential network attacks. Section 6 describes the attack and why 186 we sign the jCard in more detail. 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in 193 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 3. Protocol Operation 198 This section uses the term "intermediary" to mean the entity that 199 acts on behalf of the user in the network as opposed to the user's 200 UAS (usually, but not necessarily, their phone). The intermediary 201 could be a back-to-back user agent (B2BUA) or a SIP Proxy. 203 Figure 2 shows an overview of the call flow for a rated call. 205 +--------+ +-----------+ 206 | Called | | Call | 207 +-----+ | Party | | Analytics | +-----+ 208 | UAC | | Proxy | | Engine | | UAS | 209 +-----+ +--------+ +-----------+ +-----+ 210 | INVITE | | | 211 | --------------> | Is call OK? | | 212 | |------------------->| | 213 | | | | 214 | | Maybe Scam | | 215 | |<-------------------| | 216 | 120 | | | 217 | <-------------- | | | 218 | | INVITE (maybe scam)| | 219 | | ------------------------------> | 220 | | | | 221 | | | 180 | 222 | | <------------------------------ | 223 | | | | 224 Caller cancels, leaves voicemail, or receives no-answer recording. 226 Figure 2: Rated (120) Ladder Diagram 228 3.1. Intermediary Operation 230 An intermediary MAY issue the 120 response code for an INVITE 231 request to indicate an intermediary rated the offered communication 232 negatively (e.g. scam) or positively (e.g. verified caller or Calling 233 Name). An intermediary MAY issue the 120 as the value of the "cause" 234 parameter of a SIP reason-value in a Reason header field [RFC3326]. 236 If an intermediary issues a 120 code and there are no indicators the 237 calling party will use the contents of the Call-Info header field for 238 malicious purposes (see Section 6), the intermediary MUST include a 239 Call-Info header field in the response. 241 If there is a Call-Info header field, it MUST have the "purpose" 242 parameter of "jwscard". The value of the Call-Info header field MUST 243 refer to a valid JSON Web Signature (JWS) [RFC7515] encoding of a 244 jCard [RFC7095] object. The following section describes the 245 construction of the JWS. 247 3.2. JWS Construction 249 The intermediary constructs the JWS of the jCard as follows. 251 3.2.1. JOSE Header 253 The Javascript Object Signing and Encryption (JOSE) header MUST 254 include the typ, alg, and x5u parameters from JWS [RFC7515]. The 255 typ parameter MUST have the value "vcard+json". Implementations 256 MUST support ES256 as JSON Web Algorithms (JWA) [RFC7518] defines it 257 and MAY support other registered signature algorithms. Finally, the 258 x5u parameter MUST be a URI that resolves to the public key 259 certificate corresponding to the key used to digitally sign the JWS. 261 3.2.2. JWT Payload 263 The payload contains two JSON values. The first JSON Web Token (JWT) 264 claim which MUST be present is the "iat" (issued at) claim [RFC7519]. 265 The "iat" MUST be set to the date and time of the issuance of the 120 266 response. This mandatory component protects the response from replay 267 attacks. 269 The second JWT claim which MUST be present is the "jcard" claim. 270 The value of the jcard [RFC7095] claim is a JSON array conforming to 271 the JSON jCard data format defined in [RFC7095]. Section 5.3 272 describes the registration. In the construction of the jcard claim, 273 the "jcard" MUST include at least one of the URL, EMAIL, TEL, or ADR 274 Properties. The Integer Property, specifically used to signal 275 rating class, MUST also be included. Integer values are defined as; 276 1(negative rating) and 2(positive rating). UACs supporting this 277 specification MUST be prepared to receive a full jCard. Call 278 originators (at the UAC) can use the information returned by the 279 jCard to contact the intermediary which rated the call and appeal 280 the intermediary's rating of the call attempt. What the intermediary 281 does if the rated caller contacts the intermediary is outside the 282 scope of this document. 284 3.2.3. JWS Signature 286 JWS [RFC7515] specifies the procedure for calculating the signature 287 over the jCard JWT. Section 4 of this document has a detailed 288 example on constructing the JWS, including the signature. 290 3.3. UAC Operation 292 A UAC conforming to this specification MUST include the sip.120 293 feature-capability indicator in the Feature-Caps header field of the 294 INVITE request. 296 Upon receiving a 120 response, UACs perform normal SIP processing for 297 1xx responses. 299 As for the disposition of the jCard itself, the UAC MUST check the 300 "iat" claim in the JWT. As noted in Section 3.2.2, we are concerned 301 about replay attacks. Therefore, the UAC MUST reject jCards that 302 come with an expired "iat". The definition of "expired" is a matter 303 of local policy. A reasonable value would be on the order of one 304 minute due to account for clock drift. 306 3.4. Legacy Interoperation 308 If the UAC indicates support for 120 and the intermediary issues a 309 120, life is good, as the UAC will receive all the information it 310 needs to remediate an erroneous rating by an intermediary. However, 311 what if the UAC does not understand 120? For example, how can we 312 support callers from a legacy, non-SIP, public-switched network 313 connecting to the SIP network via a media gateway? 315 We address this situation by having the owning service provider of 316 the first network element that conforms with this specification log 317 negatively rated call attempts for calls from their customers. 318 The simple rule is originating provider's network element inserting 319 the sip.120 feature capability MUST be able to convey at a minimum 320 the call was rated negatively and how to contact the operator of the 321 intermediary that rated the call attempt. How that information is 322 relayed to customers is outside the scope of this document. 324 The degenerate case is the intermediary is the only element that 325 understands the semantics of the 120 response code. Obviously, any 326 SIP device will understand that a 120 response code is a 1xx 327 response. However, there are no other elements in the call path that 328 understand the meaning of the value of the Call-Info header field. 329 The intermediary knows this is the case as the INVITE request will 330 not have the sip.120 feature capability. In this case, the 331 intermediary MAY opt out of inserting Call-Info given no element in 332 the origination network supports consuming it on behalf of the 333 caller. 335 Now we take the case where a network element that understands the 336 120 response code receives an INVITE for further processing. A 337 network element conforming with this specification MUST insert the 338 sip.120 feature capability per the behaviors described in Section 4.2 339 of [RFC6809]. 341 The network element MUST forward the 120 response code message as a 342 progress response to the INVITE. The ultimate disposition of the 343 call attempt MAY be a 100-class response (assuming call goes 344 unanswered due to negative rating). 346 One aspect of using a feature capability is that only the network 347 elements that will consume (UAC)(session border controller (SBC) 348 [RFC7092], or proxy) need to understand the sip.120 feature 349 capability. If the other network elements conform to Section 16.6 350 of [RFC3261], they will pass header fields such as "Feature-Caps: 351 *;+sip.120" unmodified and without need for upgrade. 353 3.5. Forking 355 There are scenarios where calls fork in serial or parallel. Based 356 on destination and intermediaries encountered through forking, UAC 357 MAY receive multiple 120 messages with varying Call-Info information. 358 Upon receiving a 120 response, UACs perform normal SIP processing for 359 1xx responses per Section 3.3. 361 4. Examples 363 These examples are not normative, do not include all protocol 364 elements, and may have errors. Review the protocol documents for 365 actual syntax and semantics of the protocol elements. 367 4.1. Full Exchange 369 Given an INVITE, shamelessly taken from [SHAKEN], with the line 370 breaks in the Identity header field for display purposes only: 372 INVITE sip:+12155550113@tel.one.example.net SIP/2.0 373 Max-Forwards: 69 374 Contact: 375 To: 376 From: "Alice" ;tag=614bdb40 377 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 378 P-Asserted-Identity: "Alice", 379 380 CSeq: 2 INVITE 381 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, 382 MESSAGE, OPTIONS 383 Content-Type: application/sdp 384 Date: Tue, 16 Aug 2016 19:23:38 GMT 385 Feature-Caps: *;+sip.120 386 Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V 387 uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ 388 hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx 389 Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN 390 DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU 391 tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info= 392 ;alg=ES256 393 Content-Length: 153 395 v=0 396 o=- 13103070023943130 1 IN IP6 2001:db8::177 397 c=IN IP6 2001:db8::177 398 t=0 0 399 m=audio 54242 RTP/AVP 0 400 a=sendrecv 401 An intermediary could reply: 403 SIP/2.0 120 Rated 404 Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1 405 From: "Alice" ;tag=614bdb40 406 To: 407 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 408 CSeq: 2 INVITE 409 Call-Info: ;purpose=jwscard 411 The location https://rated.example.net/complaint-jws resolves to a 412 JWS. One would construct the JWS as follows. 414 The JWS header of this example jCard could be: 416 { "alg":"ES256", 417 "typ":"vcard+json", 418 "x5u":"https://certs.example.net/rated_key.cer" 419 } 421 Now, let us construct a minimal jCard. For this example, the jCard 422 refers the caller to an email address, 423 remediation@rated.example.net: 425 ["vcard", 426 [ 427 ["version", {}, "text", "4.0"], 428 ["fn", {}, "text", "Call Rating Adjudication"], 429 ["email", {"type":"work"}, "text", 430 "remediation@rated.example.net"] 431 ] 432 ] 434 With this jCard, we can now construct the JWT: 436 { 437 "iat":1546008698, 438 "jcard":["vcard", 439 [ 440 ["version", {}, "text", "4.0"], 441 ["fn", {}, "text", "Call Rating Adjudication"], 442 ["email", {"type":"work"}, 443 "text", "remediation@rated.example.net"], 444 ["rating-class",{},"integer", 1] 445 ] 446 ] 447 } 448 To calculate the signature, we need to encode the JSON Object 449 Signing and Encryption (JOSE) header and JWT using base64url 450 encoding. As an implementation note, one can trim whitespace 451 in the JSON objects to save a few bytes. UACs MUST be prepared 452 to receive pretty-printed,compact, or bizarrely formatted JSON. 453 For the purposes of this example, we leave the objects with pretty 454 whitespace. Speaking of pretty vs. machine formatting, these 455 examples have line breaks in the base64url encodings for ease of 456 publication in the RFC format. The specification of base64url 457 allows for these line breaks, and the decoded text works just fine. 458 However, those extra line-break octets would affect the calculation 459 of the signature. Implementations MUST NOT insert line breaks into 460 the base64url encodings of the JOSE header or JWT. This also means 461 UACs MUST be prepared to receive arbitrarily long octet streams from 462 the URI referenced by the Call-Info header field. 464 base64encoding of JOSE header: 466 eyAiYWxnIjoiRVMyNTYiLAogICAgICJ0eXAiOiJ2Y2FyZCtqc29uIiwKICAgICAieDV1 467 IjoiaHR0cHM6Ly9jZXJ0cy5leGFtcGxlLm5ldC9yYXRlZF9rZXkuY2VyIgogICB9Cg== 469 base64encoding of JWT: 471 ewogICAgICJpYXQiOjE1NDYwMDg2OTgsCiAgICAgImpjYXJkIjpbInZjYXJkIiwKICAg 472 ICAgIFsKICAgICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAg 473 ICAgICBbImZuIiwge30sICJ0ZXh0IiwgIkNhbGwgUmF0aW5nIEFkanVkaWNhdGlvbiJd 474 LAogICAgICAgICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LAogICAgICAgICAgInRl 475 eHQiLCAicmVtZWRpYXRpb25AcmF0ZWQuZXhhbXBsZS5uZXQiXSwKCSAgW+KAnHJhdGlu 476 Zy1jbGFzc+KAnSx7fSzigJxpbnRlZ2Vy4oCdLCAxXQogICAgICAgXQogICAgIF0KICAg 477 fQ== 479 Note the object to sign is a single long line. Above line breaks are 480 for ease of review and do not appear in actual object to sign. 482 We use the X.509 PKCS #8-encoded Elliptic Curve Digital 483 Signature Algorithm (ECDSA) key, also shamelessly taken from 484 [SHAKEN], as an example key for signing the hash of the above text. 486 Please do NOT use this key in real life! It is for example 487 purposes only. We strongly recommend encrypting your key at rest. 489 -----Example object to sign / Base 64 Jose + JWT----- 490 eyAiYWxnIjoiRVMyNTYiLAogICAgICJ0eXAiOiJ2Y2FyZCtqc29uIiwKICAgICAieDV 491 1IjoiaHR0cHM6Ly9jZXJ0cy5leGFtcGxlLm5ldC9yYXRlZF9rZXkuY2VyIgp9CnsKIC 492 AgICAiaWF0IjoxNTQ2MDA4Njk4LAogICAgICJqY2FyZCI6WyJ2Y2FyZCIsCiAgICAgI 493 CBbCiAgICAgICAgIFsidmVyc2lvbiIsIHt9LCAidGV4dCIsICI0LjAiXSwKICAgICAg 494 ICAgWyJmbiIsIHt9LCAidGV4dCIsICJDYWxsIFJhdGluZyBBZGp1ZGljYXRpb24iXSw 495 KICAgICAgICAgWyJlbWFpbCIsIHsidHlwZSI6IndvcmsifSwKICAgICAgICAgICJ0ZX 496 h0IiwgInJlbWVkaWF0aW9uQHJhdGVkLmV4YW1wbGUubmV0Il0sCgkgIFvigJxyYXRpb 497 mctY2xhc3PigJ0se30s4oCcaW50ZWdlcuKAnSwgMV0KICAgICAgIF0KICAgICBdCiAg 498 IH0= 499 -----BEGIN PRIVATE KEY----- 500 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy 501 qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW 502 ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh 503 -----END PRIVATE KEY----- 505 -----BEGIN PUBLIC KEY----- 506 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 507 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 508 -----END PUBLIC KEY----- 510 The resulting JWS, using the above key on the above object, renders 511 the following ECDSA P-256 SHA-256 digital signature. 513 3045022100d6ac15779808d4d6c99082a85fd129ff5faac25ba96dbef5d615f3586 514 a7c5060022077e450ebd83cf04a9e74a4858b592fe92cf682d487ead8e74c8d624a 515 f8f2c5a4 517 The JWS would be stored at https://rated.example.net/complaint-jws 519 4.2. Web Site jCard 521 For an intermediary that provides a Web site for adjudication, the 522 jCard could contain the following. Note we do not show the 523 calculation of the JWS; the URI reference in the Call-Info header 524 field would be to the JWS of the signed jCard. 526 ["vcard", 527 [ 528 ["version", {}, "text", "4.0"], 529 ["fn", {}, "text", "Rated Call Adjudication"], 530 ["url", {"type":"work"}, 531 "text", "https://rated.example.net/adjudication-form"], 532 ['rating-class',{},'integer', 1] 533 ] 534 ] 535 4.3. Multi-modal jCard 537 For an intermediary that provides a telephone number and a postal 538 address, the jCard could contain the following. Note that we do not 539 show the calculation of the JWS; the URI reference in the Call-Info 540 header field would be to the JWS of the signed jCard. 542 ["vcard", 543 [ 544 ["version", {}, "text", "4.0"], 545 ["fn", {}, "text", "Rated Call Adjudication"], 546 ["adr", {"type":"work"}, "text", 547 ["Argument Clinic", 548 "12 Main St","Anytown","AP","000000","Somecountry"] 549 ] 550 ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"], 551 ['rating-class',{},'integer', 1] 552 ] 553 ] 555 Note that it is up to the UAC to decide which jCard contact modality, 556 if any, it will use. 558 4.4. Legacy Interoperability 560 Figure 3 depicts a call flow illustrating legacy interoperability. 561 In this non-normative example, we see a UAC that does not support 562 the full semantics for 120. However, there is an SBC that does 563 support 120. Per [RFC6809], the SBC can insert "*;+sip.120" into 564 the Feature-Caps header field for the INVITE. When the 565 intermediary, labeled "Called Party Proxy" in the figure, rates the 566 call, it knows it can simply perform the processing described in 567 this document. Since the intermediary saw the sip.120 feature 568 capability, it knows it can add Call-Info describing whom to contact 569 in the event of an erroneous rating. The SBC in this case is owned 570 by the caller's originating service provider. The SBC has the 571 capability to surface the Call-Info data to the SP who may then 572 make their customer's aware of negative rating or proactively reach 573 out to call rating contact on customer's behalf per local policy. 575 For illustrative purposes, the figure shows generic SIP Proxies in 576 the flow. Their presence or absence or the number of proxies is not 577 relevant to the operation of the protocol. They are in the figure 578 to show proxies that do not understand the sip.120 feature 579 capability can still participate in a network offering 120 services. 581 +---------+ 582 | Call | 583 |Analytics| 584 | Engine | 585 +--+--+---+ 586 ^ | 587 | v 588 +-+--+-+ 589 +---+ +-----+ +---+ +-----+ +-----+ |Called| 590 |UAC+----+Proxy+----+SBC+----+Proxy+----+Proxy+----+Party | 591 +---+ +-----+ +---+ +-----+ +-----+ |Proxy | 592 | | +------+ 593 | INVITE | | 594 |------------------>| | 595 | | INVITE | 596 | |------------------------------>| 597 | | Feature-Caps: *;+sip.120 | 598 | | | 599 | | 120 Rated | 600 | 120 Rated |<------------------------------| 601 |<------------------| Call-Info: <...> | 602 | | [path for Call-Info elided | 603 | | for illustration purposes]| 604 | | | 606 Figure 3: Legacy Operation 608 When the SBC receives the 120 response code, it correlates that with 609 the original INVITE from the UAC. The SBC remembers it inserted 610 the sip.120 feature capability, which means it is responsible for 611 somehow alerting the UAC the call is rated and disclosing whom to 612 contact. At this point, it's up to the SBC owner to monitor for 613 this scenario and inform their customers or act on their behalf. 615 Note the SBC also still sends the full 120 response code, including 616 the Call-Info header field, towards the UAC. 618 5. IANA Considerations 620 5.1. SIP Response Code 622 This document defines a new SIP response code, 120, in the "Response 623 Codes" subregistry of the "Session Initiation Protocol (SIP) 624 Parameters" registry defined in [RFC3261]. 626 Response code: 120 627 Description: Rated 628 Reference: TBD 630 5.2. SIP Feature-Capability Indicator 632 This document defines the feature capability, sip.120, in the "SIP 633 Feature-Capability Indicator Registration Tree" registry defined in 634 [RFC6809]. 636 Name: sip.120 637 Description: This feature-capability indicator, when included in a 638 Feature-Caps header field of an INVITE request, 639 indicates the entity associated with the indicator 640 will be responsible for indicating to the caller any 641 information contained in the 120 SIP response code, 642 specifically, the value referenced by the Call-Info 643 header field. 644 Reference: TBD 646 5.3. JSON Web Token Claim 648 This document defines the new JSON Web Token claim in the "JSON Web 649 Token Claims" subregistry created by [RFC7519]. Section 3.2.2 650 defines the syntax. The required information is: 652 Claim Name: jcard 653 Claim Description: jCard data 654 Change Controller: IESG 655 Reference: [RFC8688], [RFC7095] 656 5.4. Call-Info Purpose 658 This document defines the new predefined value "jwscard" for the 659 "purpose" header field parameter of the Call-Info header field. 660 This modifies the "Header Field Parameters and Parameter Values" 661 subregistry of the "Session Initiation Protocol (SIP) Parameters" 662 registry by adding this RFC as reference to the line for the header 663 field "Call-Info" and parameter name "purpose": 665 Header Field: Call-Info 666 Parameter Name: purpose 667 Predefined Values: Yes 668 Reference: TBD 670 6. Security Considerations 672 Intermediary operators need to be mindful to whom they are sending 673 the 120 response. The intermediary could be rating a truly 674 malicious caller. This raises two issues. The first is the caller, 675 now alerted that an intermediary is poorly rating their 676 call attempts, may change their call behavior to defeat call-rating 677 systems. The second, and more significant risk, is by providing 678 a contact in the Call-Info header field, the intermediary may be 679 giving the malicious caller a vector for attack. In other words, 680 intermediary will be publishing an address which a malicious actor 681 may use to launch an attack on the intermediary. Because of this, 682 we recommend intermediary operators configure their response to only 683 include a Call-Info header field for signed INVITE passing 684 validation by STIR [RFC8224]. 686 Another risk is as follows. Consider an attacker that floods a 687 proxy supporting sip.120 feature. However, the SDP in the INVITE 688 request refers to a victim device. Moreover, the attacker somehow 689 knows there is a 120-aware gateway connecting to the victim who is 690 on a segment that lacks the sip.120 feature capability. Because the 691 mechanism described here can result in sending an audio file to the 692 target of the SDP, an attacker could use the mechanism described by 693 this document as an amplification attack, given a SIP INVITE can be 694 under 1 kilobyte and an audio file can be hundreds of kilobytes. 695 One remediation for this is for devices inserting a sip.120 feature 696 capability to only transmit media to what is highly likely to be the 697 actual source of the call attempt. A method for this is to only play 698 media in response to a STIR-signed INVITE which passes validation. 699 Beyond requiring a valid STIR signature on the INVITE, the 700 intermediary can also use remediation procedures such as performing 701 connectivity checks specified by Interactive Connectivity 702 Establishment [RFC8445]. If the target did not request the media, 703 the checks will fail. 705 Yet another risk is a malicious intermediary generating a 706 malicious 120 response with a jCard referring to a malicious agent. 707 For example, the recipient of a 120 may receive a TEL URI in the 708 vCard. When the recipient calls that address, the malicious agent 709 could ask for personally identifying information. Instead 710 of using that information to verify the recipient's identity, they 711 are phishing information for nefarious ends. A similar scenario 712 can unfold if the malicious agent inserts a URI which points to a 713 phishing or other mal-intent site. As such, we strongly recommend 714 the recipient validates to whom they are communicating with if 715 asking to adjudicate an erroneously rated call attempt. Since we 716 may also be concerned about intermediate nodes modifying contact 717 information, we can address both issues with a single solution. 718 The remediation is to require the intermediary to sign the jCard. 719 Signing the jCard provides integrity protection. In addition, 720 one can imagine mechanisms such as used by [SHAKEN]. 722 Similarly, one can imagine an adverse agent maliciously spoofs a 723 120 response with a victim's contact address to many active callers 724 who may then all send redress requests to the specified address (the 725 basis for a denial-of-service attack). The process would occur as 726 follows: (1) a malicious agent senses INVITE requests from a variety 727 of UACs and (2) spoofs 120 responses with an unsigned redress address 728 before the intended receivers can respond, causing (3) the UACs to 729 all contact the redress address at once. The jCard encoding allows 730 the UAC to verify the blocking intermediary's identity before 731 contacting the redress address. Specifically, because the sender 732 signs the jCard, we can cryptographically trace the sender of the 733 jCard. Given the protocol machinery of having a signature, one can 734 apply local policy to decide whether to believe that the sender of 735 the jCard represents the owner of the contact information found in 736 the jCard. This guards against a malicious agent spoofing 120 737 responses. 739 Specifically, one could use policies around signing certificate 740 issuance as a mechanism for traceback to the entity issuing the 741 jCard. One check could be verifying that the identity of the subject 742 of the certificate relates to the To header field of the initial SIP 743 request, similar to validating that the intermediary was vouching for 744 the From header field of a SIP request with that identity. Note that 745 we are only protecting against a malicious intermediary and not a 746 hidden intermediary attack (formerly known as a "man-in-the-middle 747 attack"). Thus, we only need to ensure the signature is fresh, which 748 is why we include "iat". For most implementations, we assume that 749 the intermediary has a single set of contact points and will generate 750 the jCard on demand. As such, there is no need to directly correlate 751 HTTPS fetches to specific calls. However, since the intermediary is 752 in control of the jCard and Call-Info response, an intermediary may 753 choose to encode per-call information in the URI returned in a given 754 120 response. However, if the intermediary does go that route, the 755 intermediary MUST use a non-deterministic URI reference mechanism and 756 be prepared to return dummy responses to URI requests referencing 757 calls that do not exist so that attackers attempting to glean call 758 metadata by guessing URIs (and thus calls) will not get any 759 actionable information from the HTTPS GET. 761 Since the decision of whether to include Call-Info in the 120 762 response is a matter of policy, one thing to consider is whether a 763 legitimate caller can ascertain whom to contact without including 764 such information in the 120. For example, in some jurisdictions, if 765 only the terminating service provider can be the intermediary, the 766 caller can look up who the terminating service provider is based on 767 the routing information for the dialed number. Thus, the Call-Info 768 jCard could be redundant information. However, the factors going 769 into a particular service provider's or jurisdiction's choice of 770 whether to include Call-Info is outside the scope of this document. 772 7. References 774 7.1. Normative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 782 A., Peterson, J., Sparks, R., Handley, M., and E. 783 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 784 DOI 10.17487/RFC3261, June 2002, 785 . 787 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 788 Header Field for the Session Initiation Protocol (SIP)", 789 RFC 3326, DOI 10.17487/RFC3326, December 2002, 790 . 792 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 793 Indicate Support of Features and Capabilities in the 794 Session Initiation Protocol (SIP)", RFC 6809, 795 DOI 10.17487/RFC6809, November 2012, 796 . 798 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 799 DOI 10.17487/RFC7095, January 2014, 800 . 802 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 803 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 804 2015, . 806 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 807 DOI 10.17487/RFC7518, May 2015, 808 . 810 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 811 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 812 . 814 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 815 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 816 May 2017, . 818 7.2. Informative References 820 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 821 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 822 January 2008, . 824 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 825 DOI 10.17487/RFC6350, August 2011, 826 . 828 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 829 Initiation Protocol (SIP) Back-to-Back User Agents", 830 RFC 7092, DOI 10.17487/RFC7092, December 2013, 831 . 833 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 834 Telephone Identity Problem Statement and Requirements", 835 RFC 7340, DOI 10.17487/RFC7340, September 2014, 836 . 838 [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 839 RFC 8197, DOI 10.17487/RFC8197, July 2017, 840 . 842 [RFC8688] Burger, E.W.,and Nagda, B. "A SIP Response Code for 843 Rejected Calls", 844 RFC 8688, DOI 10.17487/RFC8688, December 2019, 845 . 847 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 848 "Authenticated Identity Management in the Session 849 Initiation Protocol (SIP)", RFC 8224, 850 DOI 10.17487/RFC8224, February 2018, 851 . 853 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 854 Interchange Format", STD 90, RFC 8259, 855 DOI 10.17487/RFC8259, December 2017, 856 . 858 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 859 Connectivity Establishment (ICE): A Protocol for Network 860 Address Translator (NAT) Traversal", RFC 8445, 861 DOI 10.17487/RFC8445, July 2018, 862 . 864 [SHAKEN] ATIS/SIP Forum IP-INNI Task Group, "Signature-based 865 Handling of Asserted information using toKENs (SHAKEN)", 866 ATIS 1000074, January 2017, 867 . 871 Acknowledgements 873 This document liberally lifts from [RFC8197] and [RFC8688] in its 874 text and structure. However, the mechanism and purpose of 120 is 875 quite different than either 607 or 608. Any errors are the current 876 editor's and not the editors of RFC 8197 or RFC 8688. 878 Authors Addresses: 880 Russ A. Penar 881 Microsoft 882 1 Microsoft Way 883 Redmond, WA 98052 884 United States of America 886 Email: russp@microsoft.com