idnits 2.17.1 draft-ietf-stir-passport-rcd-04.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 (July 08, 2019) is 1754 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: 'RFCThis' is mentioned on line 778, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-05 ** Downref: Normative reference to an Informational draft: draft-ietf-stir-oob (ref. 'I-D.ietf-stir-oob') ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar Inc. 4 Intended status: Standards Track C. Wendt 5 Expires: January 9, 2020 Comcast 6 July 08, 2019 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-04 11 Abstract 13 This document extends PASSporT, a token for conveying 14 cryptographically-signed call information about personal 15 communications, to include rich data that can be rendered to users, 16 such as a human-readable display name comparable to the "Caller ID" 17 function common on the telephone network. The element defined for 18 this purpose, Rich Call Data (RCD), is extensible to include related 19 information about calls that helps people decide whether to pick up 20 the phone. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 9, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . . . 3 59 3.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. "icn" key . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. "inf" key . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.4. "jcd" key . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.5. "jcl" key . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Rich Call Data integrity . . . . . . . . . . . . . . . . . . 5 65 4.1. "rcdi" RCD integrity Claim . . . . . . . . . . . . . . . 5 66 4.1.1. Creation of the "rcd" digest . . . . . . . . . . . . 6 67 4.2. JWT Constraint for "rcdi" claim . . . . . . . . . . . . . 7 68 5. "rcd" Usage . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 8 70 6. Further Information Associated with Callers . . . . . . . . . 10 71 7. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 11 72 7.1. Signing as a Third Party . . . . . . . . . . . . . . . . 12 73 8. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 13 74 9. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Authentication Service Behavior . . . . . . . . . . . . . 13 76 9.2. Verification Service Behavior . . . . . . . . . . . . . . 14 77 10. Using "rcd" as additional claims to other PASSporT extensions 15 78 10.1. Procedures for applying "rcd" as claims only . . . . . . 15 79 10.2. Example for applying "rcd" as claims only . . . . . . . 15 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 12.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 16 83 12.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 17 84 12.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 17 85 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 14.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 94 conveying cryptographically-signed information about the people 95 involved in personal communications; it is used to convey a signed 96 assertion of the identity of the participants in real-time 97 communications established via a protocol like SIP [RFC8224]. The 98 STIR problem statement [RFC7340] declared securing the display name 99 of callers outside of STIR's initial scope, so baseline STIR provides 100 no features for caller name. This specification documents an 101 optional mechanism for PASSporT and the associated STIR mechanisms 102 which extends PASSporT to carry additional elements conveying richer 103 information: information that is intended to be rendered to an end 104 user to assist a called party in determining whether to accept or 105 trust incoming communications. This includes the name of the person 106 on one side of a communications session, the traditional "Caller ID" 107 of the telephone network, along with related display information that 108 would be rendered to the called party during alerting, or potentially 109 used by an automaton to determine whether and how to alert a called 110 party. 112 Traditional telephone network signaling protocols have long supported 113 delivering a 'calling name' from the originating side, though in 114 practice, the terminating side is often left to derive a name from 115 the calling party number by consulting a local address book or an 116 external database. SIP similarly can carry a 'display-name' in the 117 From header field value from the originating to terminating side, 118 though it is an unsecured field that is not commonly trusted. The 119 same is true of information in the Call-Info header field. 121 The baseline use case for this document will be extending PASSporT to 122 provide cryptographic protection for the "display-name" field of SIP 123 requests as well as further "rich call data" (RCD) about the caller, 124 which includes the contents of the Call-Info header field or other 125 data structures that can be added to the PASSporT. This document 126 furthermore specifies a third-party profile that would allow external 127 authorities to convey rich information associated with a calling 128 number via a new type of PASSporT. Finally, this document describes 129 how to constrain the RCD data that a PASSporT can attest via 130 certificate-level controls. 132 2. Terminology 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 136 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 137 described in [RFC2119] and [RFC6919]. 139 3. PASSporT "rcd" Claim 141 This specification defines a new JSON Web Token claim for "rcd", Rich 142 Call Data, the value of which is a JSON object that can contain one 143 or more key value pairs. This document defines a default set of key 144 values. 146 3.1. "nam" key 148 The "nam" key value is a display name, associated with the originator 149 of personal communications, which may for example derive from the 150 display-name component of the From header field value of a SIP 151 request, or a similar field in other PASSporT using protocols. This 152 key MUST be included once and MUST be included as as part of the 153 "rcd" claim value JSON object. If there is no string associated with 154 a display name, the claim value SHOULD then be an empty string. 156 3.2. "icn" key 158 The "icn" key value is defined to contain a HTTPS URL that references 159 a publicly available icon or logo resource, associated with the 160 originator of personal communications. This URL is intended to and 161 may derive from the Call-Info header field value of a SIP request 162 [RFC3261] Section 20.9 with a type of "icon". This key is optional 163 but if included MUST be included as part of the "rcd" claim value 164 JSON object. The format of the icon file resource is not defined in 165 this document, but widely supported formats such as jpg, png, and svg 166 are recommended. 168 3.3. "inf" key 170 The "inf" key value is defined to contain a HTTPS URL that references 171 a publicly available webpage or HTML type of resource intended to 172 provide information about the caller. This URL is intended to and 173 may derive from the Call-Info header field value of a SIP request 174 [RFC3261] Section 20.9 with a type of "info". This key is optional 175 but if included MUST be included as part of the "rcd" claim value 176 JSON object. The format of the info resource is not specifically 177 defined by this document, but HTML based resource that can be 178 generally rendered in a standard web browser is recommended. (? can 179 we apply integrity digest to HTML content generally, since there is 180 potentially many hyperlinks contained within, or do we need more 181 rules to limit HTML content for many reasons) 183 3.4. "jcd" key 185 The "jcd" key value is defined to contain a value of a jCard 186 [RFC7095] JSON object. This jCard object is intended to and may 187 derive from the Call-Info header field value of a SIP request 188 [RFC3261] Section 20.9 with a type of "card". It is an extensible 189 object where the calling party can provide both the standard types of 190 information defined in jCard or can use the built in extensibility of 191 the jCard specification to add additional information. The "jcd" is 192 optional. If included, this key MUST only be included once in the 193 "rcd" JSON object and SHOULD NOT be included if there is a "jcl" key 194 included. The "jcd" and "jcl" keys should be mutually exclusive. 196 3.5. "jcl" key 198 The "jcl" key value is defined to contain a HTTPS URL that refers the 199 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 200 web server. This link is intended to and may derive from the Call- 201 Info header field value of a SIP request [RFC3261] Section 20.9 with 202 a type of "card". This URL is an external reference to a JSON file 203 with the same intended use of the "jcd" jCard object and has the same 204 intended properties. The "jcl" key is optional. If included, this 205 key MUST only be included once in the "rcd" JSON object and SHOULD 206 NOT be included if there is a "jcd" key included. The "jcd" and 207 "jcl" keys should be mutually exclusive. 209 4. Rich Call Data integrity 211 When incorporating call data that represents a user, even in 212 traditional calling name services today, often there is policy and 213 restrictions around what data is allowed to be used. Whether 214 preventing offensive language or icons or enforcing uniqueness or 215 whatever potential policy either via regulatory rules, a customer 216 service agreements, or an enterprise brand consistency there may be 217 the desire to pre-certify the specific use of rich data. This 218 document defines a mechanism that allows for an indirect party that 219 controls the policy to approve or certify the content, create a 220 cryptographic digest that can be used to validate that data and 221 applies a constraint in the certificate to allow the recipient and 222 verifier to validate that the specific content of the RCD is as 223 intended at its creation and approval or certification. 225 The integrity mechanism is a process of generating a sufficiently 226 strong cryptographic digest for both the "rcd" claim contents (e.g. 227 "nam" and "jcd") and the resources defined by one or more globally 228 unique HTTPS URLs referenced by the contents (e.g. "icon" or an image 229 file referenced by "jcd"). This mechanism is inspired and based on 230 the W3C Subresource Integrity specification (http://www.w3.org/TR/ 231 SRI/). This mechanism additionally defines the ability to constrain 232 the digest and RCD integrity mechanism to be mandatory without 233 modification using JWT Constraints defined in [RFC8226]. 235 4.1. "rcdi" RCD integrity Claim 237 The "rcdi" claim is an optional claim that if the application 238 requires integrity applied to the content of the "rcd" claim SHOULD 239 be included with a corresponding "rcd" claim. The value of the 240 "rcdi" key pair should contain a string that is defined as follows. 242 The first part of the string should define the crypto algorithm used 243 to generate the digest. For RCD, implementations MUST support the 244 following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA- 245 256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic 246 hash functions defined by the NIST. Implementations MAY support 247 additional algorithms, but MUST NOT support known weak algorithms 248 such as MD5 or SHA-1. In the future, the list of algorithms may re- 249 evaluated based on security best practices. The algorithms MUST be 250 represented in the text by "sha256", "sha384", or "sha512". The 251 character following the algorithm string MUST be a minus character, 252 "-". The subsequent characters MUST be the base64 encoded digest of 253 a canonicalized and concatenated string based on the "rcd" claim and 254 the URLs contained in the claim. The details of the creation of this 255 string are defined in the next section. 257 Example: 258 "rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO" 260 4.1.1. Creation of the "rcd" digest 262 In order to facilitate proper verification of the digest and whether 263 the "rcd" content was modified, the input to the digest must be 264 completely deterministic at three points in the process. First, at 265 the certification point where the content is evaluated to conform to 266 the application policy and the JWT constraint is applied to the 267 certificate containing the digest. Second, when the call is signed 268 at the Authentication Service, there may be a local policy to verify 269 that the provided "rcd" claim corresponds to the digest. Third, when 270 the "rcd" data is verified at the Verification Service, it MUST 271 verify the digest by constructing the "rcd" input digest string. 273 The procedures for the creation of the "rcd" input digest string is 274 as follows. 276 1. Arrange the keys in the "rcd" claim value to be in lexicographic 277 order. 279 2. Serialize the resulting "rcd" claim value JSON object to remove 280 all white space and line breaks. The procedures of this 281 deterministic JSON serialization is defined in [RFC8225], 282 Section 9. 284 3. Identify, in order of where they appear in the serialized string, 285 all of the URLs referencing external resource files. 287 4. Construct the "rcd" input string by first inserting the 288 serialized "rcd" claim value. 290 5. If there is at least one URL identified, insert a semicolon 291 character in the "rcd" input string. 293 6. Follow the semicolon with the Base64 encoded contents of resource 294 file referenced by the first URL. 296 7. Repeat steps 5 and 6 for any additionally identified 297 corresponding URLs. 299 Once the input digest string has been created, use this string to 300 create the base64 encoded digest output that can be inserted into the 301 "rcdi" claim as discussed in the last section. 303 Example "rcd" claim with URL: 304 "rcd": { "nam" : "James Bond", 305 "icon" : "https://example.org/james_bond.jpg" 306 } 308 Example "rcd" input digest string (with line breaks for readability): 309 {"nam":"James Bond","icon":"https://example.org/james_bond.jpg"}; 310 ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3 312 Example "rcdi" claim: 313 "rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M" 315 4.2. JWT Constraint for "rcdi" claim 317 Once both the contents of the "rcd" claim is certified and the 318 construction of the "rcdi" claim is complete, the "rcdi" digest is 319 linked to the STIR certificate associated with the signature in the 320 PASSporT via JWT Constraints as defined in [RFC8226] Section 8. 322 The certificate JWT Constraint MUST include both of the following: 324 o a "mustInclude" for the "rcd" claim 326 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 327 to the created "rcdi" claim value string. 329 5. "rcd" Usage 331 The "rcd" claim may appear in any PASSporT claims object as an 332 optional element. The creator of a PASSporT MAY however add a "ppt" 333 value of "rcd" to the header of a PASSporT as well, in which case the 334 PASSporT claims MUST contain a "rcd" claim, and any entities 335 verifying the PASSporT object will be required to understand the 336 "ppt" extension in order to process the PASSporT in question. A 337 PASSporT header with the "ppt" included will look as follows: 339 { "typ":"passport", 340 "ppt":"rcd", 341 "alg":"ES256", 342 "x5u":"https://www.example.com/cert.cer" } 344 The PASSporT claims object will then contain the "rcd" key with its 345 corresponding value. The value of "rcd" is an array of JSON objects, 346 of which one, the "nam" object, is mandatory. The key syntax of 347 "nam" follows the display-name ABNF given in [RFC3261]. 349 After the header and claims PASSporT objects have been constructed, 350 their signature is generated normally per the guidance in [RFC8225]. 352 5.1. Example "rcd" PASSporTs 354 An example of a "nam" only PASSporT claims obejct is shown next (with 355 line breaks for readability only). 357 { "orig":{"tn":"12025551000"}, 358 "dest":{"tn":"12025551001"}, 359 "iat":1443208345, 360 "rcd":{"nam":"James Bond"} } 362 An example of a "nam" only PASSporT claims object with an "rcdi" 363 claim is shown next (with line breaks for readability only). 365 { "orig":{"tn":"12025551000"}, 366 "dest":{"tn":"12025551001"}, 367 "iat":1443208345, 368 "rcd":{"nam":"James Bond"} 369 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" 370 } 372 An example of a PASSporT claims object that includes the "jcd" which 373 is optional, but will also include the mandatory "nam" object is 374 shown next (with line breaks for readability only). 376 { "orig":{"tn":"12025551000"}, 377 "dest":{"tn":"12155551001"}, 378 "iat":1443208345, 379 "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text","4.0"], 380 ["fn",{},"text", "James Bond"], 381 ["n",{},"text",["Bond","James","","","Mr."]], 382 ["adr",{"type":"work"},"text", 383 ["","","3100 Massachusetts Avenue NW","Washington","DC","20008","USA"] 384 ], 385 ["email",{},"text","007@mi6-hq.com"], 386 ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", 387 "tel:+1-202-555-1000"], 388 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], 389 ["bday",{},"date","19241116"], 390 ["logo",{},"uri", 391 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg" 392 ]]]}} 394 In an example PASSporT where a jCard is linked via HTTPS URL and 395 "jcl" a jCard file served at a particular URL will be created. 397 An example jCard JSON file is shown as follows: 399 ["vcard", 400 [ 401 ["version", {}, "text", "4.0"], 402 ["fn", {}, "text", "James Bond"], 403 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 404 ["adr", {"type":"work"}, "text", 405 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 406 "USA"] 407 ], 408 ["email", {}, "text", "007@mi6-hq.com"], 409 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 410 "tel:+1-202-555-1000"], 411 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 412 ["bday", {}, "date", "19241116"] 413 ["logo", {}, "uri", 414 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 415 ] 416 ] 418 If that jCard is hosted at the example address of 419 "https://example.org/james_bond.json", the corresponding PASSporT 420 claims object would be as follows (with line breaks for readability 421 only): 423 { "orig":{"tn":"12025551000"}, 424 "dest":{"tn":"12155551001"}, 425 "iat":1443208345, 426 "rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} 427 } 429 If we were to add a "rcdi" integrity claim to the last example, the 430 corresponding PASSporT claims object would be as follows (with line 431 breaks for readability only): 433 { "orig":{"tn":"12025551000"}, 434 "dest":{"tn":"12155551001"}, 435 "iat":1443208345, 436 "rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} 437 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" 438 } 440 6. Further Information Associated with Callers 442 Beyond naming information and the information that can be contained 443 in a jCard [RFC7095] object, there may be additional human-readable 444 information about the calling party that should be rendered to the 445 end user in order to help the called party decide whether or not to 446 pick up the phone. This is not limited to information about the 447 caller, but includes information about the call itself, which may 448 derive from analytics that determine based on call patterns or 449 similar data if the call is likely to be one the called party wants 450 to receive. Such data could include: 452 o information related to the location of the caller, or 454 o any organizations or institutions that the caller is associated 455 with, or even categories of institutions (is this a government 456 agency, or a bank, or what have you), or 458 o hyperlinks to images, such as logos or pictures of faces, or to 459 similar external profile information, or 461 o information that will be processed by an application before 462 rendering it to a user, like social networking data that shows 463 that an unknown caller is a friend-of-a-friend, or reputation 464 scores derived from crowdsourcing, or confidence scores based on 465 broader analytics about the caller and callee. 467 All of these data elements would benefit from the secure attestations 468 provided by the STIR and PASSporT frameworks. A new IANA registry 469 has been defined to hold potential values of the "rcd" array; see 470 Section 12.3. Specific extensions to the "rcd" PASSporT claim are 471 left for future specification. 473 While in the traditional telephone network, the business relationship 474 between calling customers and their telephone service providers is 475 the ultimate root of information about a calling party's name, some 476 other forms of data like crowdsourced reputation scores might derive 477 from third parties. It is more likely that when those elements are 478 present, they will be in a third-party "rcd" PASSporT. 480 7. Third-Party Uses 482 While rich data about the call can be provided by an originating 483 authentication service, the terminating side or an intermediary in 484 the call path could also acquire rich call data by querying a third- 485 party service. Such a service effectively acts as a STIR 486 Authentication Service, generating its own PASSporT, and that 487 PASSporT could be attached to a SIP call by either the originating or 488 terminating side. This third-party PASSporT attests information 489 about the calling number, rather than the call or caller itself, and 490 as such its RCD MUST NOT be used when a call lacks a first-party 491 PASSporT that assures verification services that the calling party 492 number is not spoofed. It is intended to be used in cases when the 493 originating side does not supply a display-name for the caller, so 494 instead some entity in the call path invokes a third-party service to 495 provide rich caller data for a call. 497 In telephone operations today, a third-party information service is 498 commonly queried with the calling party's number in order to learn 499 the name of the calling party, and potentially other helpful 500 information could also be passed over that interface. The value of 501 using a PASSporT to convey this information from third parties lies 502 largely in the preservation of the original authority's signature 503 over the data, and the potential for the PASSporT to be conveyed from 504 intermediaries to endpoint devices. Effectively, these use cases 505 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 506 manner in which third-party services are discovered is outside the 507 scope of this document. 509 An intermediary use case might look as follows: a SIP INVITE carries 510 a display name in its From header field value and an initial PASSporT 511 object without the "rcd" claim. When the a terminating verification 512 service implemented at a SIP proxy server receives this request, and 513 determines that the signature is valid, it might query a third-party 514 service that maps telephone numbers to calling party names. Upon 515 receiving the PASSport in a response from that third-party service, 516 the terminating side could add a new Identity header field to the 517 request for the "rcd" PASSporT object provided by the third-party 518 service. It would then forward the INVITE to the terminating user 519 agent. If the display name in the "rcd" PASSporT object matches the 520 display name in the INVITE, then the name would presumably be 521 rendered to the end user by the terminating user agent. 523 A very similar flow could be followed by an intermediary closer to 524 the origination of the call. Presumably such a service could be 525 implemented at an originating network in order to decouple the 526 systems that sign for calling party numbers from the systems that 527 provide rich data about calls. 529 In an alternative use case, the terminating user agent might query a 530 third-party service. In this case, no new Identity header field 531 would be generated, though the terminating user agent might receive a 532 PASSporT object in return from the third-party service, and use the 533 "rcd" field in the object as a calling name to render to users while 534 alerting. 536 7.1. Signing as a Third Party 538 When a third party issues a PASSporT with an "rcd" claim, the 539 PASSporT MUST contain the "rcd" "ppt" type in its header object. It 540 moreover MUST include an "iss" claim as defined in [RFC7519] to 541 indicate the source of this PASSporT; that field SHOULD be populated 542 with the subject of the credential used to sign the PASSporT. 544 A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that 545 do not have authority over the identity that appears in the "orig" 546 element of the PASSporT claims. Relying parties in STIR have always 547 been left to make their own authorization decisions about whether or 548 not the trust the signers of PASSporTs, and in the third-party case, 549 where an entity has explicitly queried a service to acquire the 550 PASSporT object, it may be some external trust or business 551 relationship that induces the relying party to trust a PASSporT. 553 An example of a Third Party issued PASSporT claims object is as 554 follows. 556 { "orig":{"tn":"12025551000"}, 557 "dest":{"tn":"12025551001"}, 558 "iat":1443208345, 559 "iss":"Example, Inc.", 560 "rcd":{"nam":"James Bond"} } 562 8. Levels of Assurance 564 As "rcd" can be provided by either first or third parties, relying 565 parties could benefit from an additional claim that indicates the 566 relationship of the attesting party to the caller. Even in first 567 party cases, this admits of some complexity: the Communications 568 Service Provider (CSP) to which a number was assigned might in turn 569 delegate the number to a reseller, who would then sell the number to 570 an enterprise, in which case the CSP might have little insight into 571 the caller's name. In third party cases, a caller's name could 572 derive from any number of data sources, on a spectrum between public 573 data scraped from web searches to a direct business relationship to 574 the caller. As multiple PASSporTs can be associated with the same 575 call, potentially a verification service could receive attestations 576 of the caller name from multiple sources, which have different levels 577 of granularity or accuracy. 579 Therefore PASSporTs that carry "rcd" data SHOULD also carry an 580 indication of the relationship of the generator of the PASSporT to 581 the caller. [TBD claim - take from SHAKEN?] 583 9. Using "rcd" in SIP 585 This section specifies SIP-specific usage for the "rcd" claim in 586 PASSporT, and in the SIP Identity header field value. Other using 587 protocols of PASSporT may define their own usages for the "rcd" 588 claim. 590 9.1. Authentication Service Behavior 592 An authentication service creating a PASSporT containing a "rcd" 593 claim MAY include a "ppt" for "rcd" or not. Third-party 594 authentication services following the behavior in Section 7.1 MUST 595 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 596 SIP authentication services MUST add a "ppt" parameter to the 597 Identity header containing that PASSporT with a value of "rcd". The 598 resulting Identity header might look as follows: 600 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 601 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 602 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 603 info=;alg=ES256;ppt="rcd" 605 This specification assumes that by default, a SIP authentication 606 service will derive the value of "rcd", specifically only for the 607 "nam" key value, from the display-name component of the From header 608 field value of the request, alternatively for some calls this may 609 come from the P-Asserted-ID header. It is however a matter of 610 authentication service policy to decide how it populates the value of 611 "rcd" and "nam" key, which MAY also derive from other fields in the 612 request, from customer profile data, or from access to external 613 services. If the authentication service generates a PASSporT object 614 containing "rcd" with a value that is not equivalent to the From 615 header field display-name value, it MUST use the full form of the 616 PASSporT object in SIP. 618 9.2. Verification Service Behavior 620 [RFC8224] Section 6.2 Step 5 requires that specifications defining 621 "ppt" values describe any additional verifier behavior. The behavior 622 specified for the "ppt" values of "rcd" is as follows. If the 623 PASSporT is in compact form, then the verification service SHOULD 624 extract the display-name from the From header field value, if any, 625 and use that as the value for the "rcd" key when it recomputes the 626 header and claims of the PASSporT object. If the signature validates 627 over the recomputed object, then the verification should be 628 considered successful. 630 However, if the PASSport is in full form with a "ppt" value of "rcd", 631 then the verification service MUST extract the value associated with 632 the "rcd" "nam" key in the object. If the signature validates, then 633 the verification service can use the value of the "rcd" "nam" key as 634 the display name of calling party, which would in turn be rendered to 635 alerted users or otherwise leveraged in accordance with local policy. 636 This will allow SIP networks that convey the display name through a 637 field other than the From header field to interoperate with this 638 specification. 640 The third-party "rcd" PASSporT cases presents some new challenges, as 641 an attacker could attempt to cut-and-paste such a third-party 642 PASSporT into a SIP request in an effort to get the terminating user 643 agent to render the display name or confidence values it contains to 644 a call that should have no such assurance. A third-party "rcd" 645 PASSporT provides no assurance that the calling party number has not 646 been spoofed: if it is carried in a SIP request, for example, then 647 some other PASSporT in another Identity header field value would have 648 to carry a PASSporT attesting that. A verification service MUST 649 determine that the calling party number shown in the "orig" of the 650 "rcd" PASSporT corresponds to the calling party number of the call it 651 has received, and that the "iat" field of the "rcd" PASSporT is 652 within the date interval that the verification service would 653 ordinarily accept for a PASSporT. 655 Verification services may alter their authorization policies for the 656 credentials accepted to sign PASSporTs when third parties generate 657 PASSporT objects, per Section 7.1. This may include accepting a 658 valid signature over a PASSporT even if it is signed with a 659 credential that does not attest authority over the identity in the 660 "orig" claim of the PASSporT, provided that the verification service 661 has some other reason to trust the signer. No further guidance on 662 verification service authorization policy is given here. 664 The behavior of a SIP UAS upon receiving an INVITE containing a 665 PASSporT object with a "rcd" claim will largely remain a matter of 666 implementation policy. In most cases, implementations would render 667 this calling party name information to the user while alerting. Any 668 user interface additions to express confidence in the veracity of 669 this information are outside the scope of this specification. 671 10. Using "rcd" as additional claims to other PASSporT extensions 673 Rich Call Data, including, for example, calling name information, is 674 often data that is additive data to the personal communications 675 information defined in the core PASSporT data required to support the 676 security properties defined in [RFC8225]. For cases where the entity 677 that is originating the personal communications and additionally is 678 supporting the authentication service and also is the authority of 679 the Rich Call Data, rather than creating multiple identity headers 680 with multiple PASSporT extensions or defining multiple combinations 681 and permutations of PASSporT extension definitions, the 682 authentication service can alternatively directly add the "rcd" 683 claims to the PASSporT it is creating, whether it is constructed with 684 a PASSporT extension or not. 686 10.1. Procedures for applying "rcd" as claims only 688 For a given PASSporT using some other extension than "rcd", the 689 Authentication Service MAY additionally include the "rcd" claim as 690 defined in this document. This would result in a set of claims that 691 correspond to the original intended extension with the addition of 692 the "rcd" claim. 694 The Verification service that receives the PASSporT, if it supports 695 this specification and chooses to, should interpret the "rcd" claim 696 as simply just an additional claim intended to deliver and/or 697 validate delivered Rich Call Data. 699 10.2. Example for applying "rcd" as claims only 701 In the case of [I-D.ietf-stir-passport-shaken] which is the PASSporT 702 extension supporting the SHAKEN specification [ATIS-1000074], a 703 common case for an Authentication service to co-exist in a CSP 704 network along with the authority over the calling name used for the 705 call. Rather than require two identity headers, the CSP 706 Authentication Service can apply both the SHAKEN PASSporT claims and 707 extension and simply add the "rcd" required claims defined in this 708 document. 710 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 711 claims would be as follows: 713 Protected Header 714 { 715 "alg":"ES256", 716 "typ":"passport", 717 "ppt":"shaken", 718 "x5u":"https://cert.example.org/passport.cer" 719 } 720 Payload 721 { 722 "attest":"A", 723 "dest":{"tn":["12025551001"]}, 724 "iat":1443208345, 725 "orig":{"tn":"12025551000"}, 726 "origid":"123e4567-e89b-12d3-a456-426655440000", 727 "rcd":{"nam":"James Bond"} 728 } 730 A Verification Service that supports "rcd" and "shaken" PASSporT 731 extensions will be able to receive the above PASSporT and interpret 732 both the "shaken" claims as well as the "rcd" defined claim. 734 If the Verification Service only understands the "shaken" extension 735 claims but doesn't support "rcd", the "rcd" can simply be ignored and 736 disregarded. 738 11. Acknowledgements 740 We would like to thank Robert Sparks and Russ Housley for helpful 741 suggestions. 743 12. IANA Considerations 745 12.1. JSON Web Token Claim 747 This specification requests that the IANA add two new claims to the 748 JSON Web Token Claims registry as defined in [RFC7519]. 750 Claim Name: "rcd" 752 Claim Description: Rich Call Data Information 753 Change Controller: IESG 755 Specification Document(s): [RFCThis] 757 Claim Name: "rcdi" 759 Claim Description: Rich Call Data Integrity Information 761 Change Controller: IESG 763 Specification Document(s): [RFCThis] 765 12.2. PASSporT Types 767 This specification requests that the IANA add a new entry to the 768 PASSporT Types registry for the type "rcd" which is specified in 769 [RFCThis]. 771 12.3. PASSporT RCD Types 773 This document requests that the IANA create a new registry for 774 PASSporT RCD types. Registration of new PASSporT RCD types shall be 775 under the Specification Required policy. 777 This registry is to be initially populated with three values, "nam", 778 "icn", "inf", "jcd", and "jcl", which are specified in [RFCThis]. 780 13. Security Considerations 782 Revealing information such as the name, location, and affiliation of 783 a person necessarily entails certain privacy risks. Baseline 784 PASSporT has no particular confidentiality requirement, as the 785 information it signs over in a using protocol like SIP is all 786 information that SIP carries in the clear anyway. Transport-level 787 security can hide those SIP fields from eavesdroppers, and the same 788 confidentiality mechanisms would protect any PASSporT(s) carried in 789 SIP. 791 More TBD. 793 14. References 795 14.1. Normative References 797 [I-D.ietf-stir-oob] 798 Rescorla, E. and J. Peterson, "STIR Out-of-Band 799 Architecture and Use Cases", draft-ietf-stir-oob-05 (work 800 in progress), July 2019. 802 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 803 A., Peterson, J., Sparks, R., Handley, M., and E. 804 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 805 DOI 10.17487/RFC3261, June 2002, 806 . 808 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 809 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 810 DOI 10.17487/RFC6919, April 2013, 811 . 813 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 814 DOI 10.17487/RFC7095, January 2014, 815 . 817 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 818 Telephone Identity Problem Statement and Requirements", 819 RFC 7340, DOI 10.17487/RFC7340, September 2014, 820 . 822 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 823 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 824 . 826 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 827 "Authenticated Identity Management in the Session 828 Initiation Protocol (SIP)", RFC 8224, 829 DOI 10.17487/RFC8224, February 2018, 830 . 832 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 833 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 834 . 836 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 837 Credentials: Certificates", RFC 8226, 838 DOI 10.17487/RFC8226, February 2018, 839 . 841 14.2. Informative References 843 [ATIS-1000074] 844 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 845 of Asserted information using toKENs (SHAKEN) 846 ", January 2017. 849 [I-D.ietf-stir-passport-shaken] 850 Wendt, C. and M. Barnes, "PASSporT SHAKEN Extension 851 (SHAKEN)", draft-ietf-stir-passport-shaken-08 (work in 852 progress), March 2019. 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 Authors' Addresses 861 Jon Peterson 862 Neustar Inc. 863 1800 Sutter St Suite 570 864 Concord, CA 94520 865 US 867 Email: jon.peterson@neustar.biz 869 Chris Wendt 870 Comcast 871 Comcast Technology Center 872 Philadelphia, PA 19103 873 USA 875 Email: chris-ietf@chriswendt.net