idnits 2.17.1 draft-ietf-stir-passport-rcd-07.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 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Compact form of an "rcd" PASSporT claim has some restrictions but mainly follows standard PASSporT compact form procedures. For re-construction of the "nam" claim the string for the display-name in the From header field. For re-construction of the "jcl", the Call-Info header as with purpose "jcard" defined in [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be used as part of compact form. -- The document date (November 02, 2020) is 1264 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 915, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-callinfo-rcd-00 ** 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: May 6, 2021 Comcast 6 November 02, 2020 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-07 11 Abstract 13 This document extends PASSporT, a token for conveying 14 cryptographically-signed call information about personal 15 communications, to include rich meta-data about a call and caller 16 that can be signed and integrity protected, transmitted, and 17 subsequently rendered to users. This framework is intended to extend 18 caller and call specific information beyond human-readable display 19 name comparable to the "Caller ID" function common on the telephone 20 network. The JSON element defined for this purpose, Rich Call Data 21 (RCD), is an extensible object defined to either be used as part of 22 STIR or with SIP Call-Info to include related information about calls 23 that helps people decide whether to pick up the phone. This signing 24 of the RCD information is also enhanced with a integrity mechanism 25 that is designed to protect the authoring and transport of this 26 information between authoritative and non-authoritative parties 27 authoring and signing the Rich Call Data for support of different 28 usage and content policies. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 6, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview of the use of the Rich Call Data PASSporT extension 4 67 4. Overview of Rich Call Data integrity . . . . . . . . . . . . 5 68 5. PASSporT Claims . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. PASSporT "rcd" Claim . . . . . . . . . . . . . . . . . . 6 70 5.1.1. "nam" key . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1.2. "jcd" key . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1.3. "jcl" key . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1.4. "rcdi" RCD integrity Claim . . . . . . . . . . . . . 7 74 5.1.5. Creation of the "rcd" digest . . . . . . . . . . . . 7 75 5.1.6. JWT Constraint for "rcdi" claim . . . . . . . . . . . 9 76 5.2. PASSporT "crn" claim - Call Reason . . . . . . . . . . . 9 77 5.2.1. JWT Constraint for "cdn" claim . . . . . . . . . . . 9 78 6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 9 79 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 10 80 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 12 81 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 12 82 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 12 83 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 12 84 8. Further Information Associated with Callers . . . . . . . . . 13 85 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 13 86 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 15 87 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 15 88 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 16 89 11.1. Authentication Service Behavior . . . . . . . . . . . . 16 90 11.2. Verification Service Behavior . . . . . . . . . . . . . 16 91 12. Using "rcd" as additional claims to other PASSporT extensions 18 92 12.1. Procedures for applying "rcd" as claims only . . . . . . 18 93 12.2. Example for applying "rcd" as claims only . . . . . . . 18 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 95 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19 97 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 20 98 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 20 99 15. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 16.2. Informative References . . . . . . . . . . . . . . . . . 22 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 105 1. Introduction 107 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 108 conveying cryptographically-signed information about the people 109 involved in personal communications; it is used to convey a signed 110 assertion of the identity of the participants in real-time 111 communications established via a protocol like SIP [RFC8224]. The 112 STIR problem statement [RFC7340] declared securing the display name 113 of callers outside of STIR's initial scope, so baseline STIR provides 114 no features for caller name. This specification documents an 115 optional mechanism for PASSporT and the associated STIR procedures 116 which extend PASSporT objects to carry additional elements conveying 117 richer information: information that is intended to be rendered to an 118 end user to assist a called party in determining whether to accept or 119 trust incoming communications. This includes the name of the person 120 on one side of a communications session, the traditional "Caller ID" 121 of the telephone network, along with related display information that 122 would be rendered to the called party during alerting, or potentially 123 used by an automaton to determine whether and how to alert a called 124 party. 126 Traditional telephone network signaling protocols have long supported 127 delivering a 'calling name' from the originating side, though in 128 practice, the terminating side is often left to derive a name from 129 the calling party number by consulting a local address book or an 130 external database. SIP similarly can carry this information in a 131 'display-name' in the From header field value from the originating to 132 terminating side, or alternatively in the Call-Info header field. 133 However, both are unsecured fields that really can not be trusted in 134 most interconnected SIP deployments, and therefore is a good starting 135 point for a framework that utilizes STIR techniques and procedures 136 for protecting call related information including but not limited to 137 calling name. 139 As such, the baseline use-case for this document will be extending 140 PASSporT to provide cryptographic protection for the "display-name" 141 field of SIP requests as well as further "rich call data" (RCD) about 142 the caller, which includes the contents of the Call-Info header field 143 or other data structures that can be added to the PASSporT. This 144 document furthermore specifies a third-party profile that would allow 145 external authorities to convey rich information associated with a 146 calling number via a new type of PASSporT. Finally, this document 147 describes how to preserve the integrity of the RCD in scenarios where 148 there may be non-authoritative users that may be initiating and 149 signing RCD and therefore a constraint on the RCD data that a 150 PASSporT can attest via certificate-level controls. 152 2. Terminology 154 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 155 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 156 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 157 described in [RFC2119] and [RFC6919]. 159 3. Overview of the use of the Rich Call Data PASSporT extension 161 The main intended use of the signing of Rich Call Data (RCD) using 162 STIR [RFC8224] and as a PASSporT extension [RFC8225] is from an 163 entity that is associated with the origination of a call. Either 164 directly the caller themselves, if they are authoritative, or a 165 service provider or third-party service that may be authoritative 166 over the rich call data on behalf of the caller. 168 The RCD described in this document is of two main categories. The 169 first data is a more traditional set of info about a caller 170 associated with "display-name" in SIP [RFC3261] and typically is the 171 calling name that is a textual description of the caller. The second 172 data is a set of RCD that is defined as part of the jCard definitions 173 or extensions to that data. [I-D.ietf-sipcore-callinfo-rcd] 174 describes the optional use of jCard in Call-Info header field as RCD 175 with the "jcard" Call-Info purpose token. Either or both of these 176 two types of data can be incorporated into a "rcd" claim defined in 177 this document. 179 Additionally, [I-D.ietf-sipcore-callinfo-rcd] also describes a 180 "reason" parameter intended for description of the intent or reason 181 for a particular call. A new claim "crn", or call reason, can 182 contain the string or object that describes the intent of the call. 183 This claim is intentionally kept separate from the "rcd" claim 184 because it is envisioned that call reason is not the same as 185 information associated with the caller and may change on a more 186 frequent, per call, type of basis. 188 In addition to the type of RCD that can be signed, there are three 189 modes of use of the signing of Rich Call Data (RCD). The first and 190 simplest mode is exclusively for when all RCD content is directly 191 included as part of the claims (i.e. no URIs are included in the 192 content). In this mode the set of claims is signed via standard 193 PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The 194 second mode is an extension of the first where a "rcd" claim is 195 included and the content includes a URI identifying external 196 resources. In this mode, a "rcdi" integrity claim MUST be included. 197 This integrity claim is defined later in this document and provides a 198 digest of the content so that, particularly for the case where there 199 is URI references in the RCD, the content of that RCD can be 200 comprehensively validated that it was received as intended by the 201 signer of the PASSporT. The third mode is an extension to both the 202 first and second modes and incorporates the ability to include the 203 digest of the integrity claim as a required value, using JWT 204 Constraints as defined in [RFC8226], in the certificate used to 205 create the PASSporT digital signature. This mode allows for cases 206 where there is a different authoritative entity responsible for the 207 content of the RCD, separate from the signer of the PASSporT itself 208 allowing the ability to have policy around the content and potential 209 review or pre-determination of allowed RCD content. 211 More generally, either of the claims defined in this or future 212 specifications content can be protected by the authoritative 213 certificate creators by inclusion in the [RFC8226] defined 214 certificate's JWT Constraints. 216 4. Overview of Rich Call Data integrity 218 When incorporating call data that represents a user, even in 219 traditional calling name services today, often there is policy and 220 restrictions around what data is allowed to be used. Whether 221 preventing offensive language or icons or enforcing uniqueness, 222 potential copyright violations or other policy enforcement, there 223 will likely be the desire to pre-certify the specific use of rich 224 call data. This document defines a mechanism that allows for an 225 indirect party that controls the policy to approve or certify the 226 content, create a cryptographic digest that can be used to validate 227 that data and applies a constraint in the certificate to allow the 228 recipient and verifier to validate that the specific content of the 229 RCD is as intended at its creation and approval or certification. 231 The integrity mechanism is a process of generating a sufficiently 232 strong cryptographic digest for both the "rcd" claim contents (e.g. 233 "nam" and "jcd") defined below and the resources defined by one or 234 more globally unique HTTPS URLs referenced by the contents (e.g. an 235 image file referenced by "jcd"). This mechanism is inspired and 236 based on the W3C Subresource Integrity specification 237 (http://www.w3.org/TR/SRI/). This mechanism additionally defines the 238 ability to constrain the digest and RCD integrity mechanism to be 239 mandatory without modification using JWT Constraints defined in 240 [RFC8226]. 242 5. PASSporT Claims 244 5.1. PASSporT "rcd" Claim 246 This specification defines a new JSON Web Token claim for "rcd", Rich 247 Call Data, the value of which is a JSON object that can contain one 248 or more key value pairs. This document defines a default set of key 249 values. 251 5.1.1. "nam" key 253 The "nam" key value is a display name, associated with the originator 254 of personal communications, which may for example derive from the 255 display-name component of the From header field value of a SIP 256 request, or a similar field in other PASSporT using protocols. This 257 key MUST be included once and MUST be included as part of the "rcd" 258 claim value JSON object. If there is no string associated with a 259 display name, the claim value SHOULD then be an empty string. 261 5.1.2. "jcd" key 263 The "jcd" key value is defined to contain a value of a jCard 264 [RFC7095] JSON object. This jCard object is intended to represent 265 and derives from the Call-Info header field value defined in 266 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 267 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 268 properties used should follow the normative usage and formatting 269 rules and procedures. It is an extensible object where the calling 270 party can provide both the standard types of information defined in 271 jCard or can use the built-in extensibility of the jCard 272 specification to add additional information. The "jcd" is optional. 273 If included, this key MUST only be included once in the "rcd" JSON 274 object and SHOULD NOT be included if there is a "jcl" key included. 275 The "jcd" and "jcl" keys should be mutually exclusive. 277 Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 278 definition of the jcard properties for usage in a "rcd" PASSporT, 279 other protocols can be adapted for use of "jcd" (or similarly "jcl" 280 below) key beyond SIP and Call-Info. 282 5.1.3. "jcl" key 284 The "jcl" key value is defined to contain a HTTPS URL that refers the 285 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 286 web server. This link may derive from the Call-Info header field 287 value defined in [I-D.ietf-sipcore-callinfo-rcd] with a type of 288 "jcard". As also defined in [I-D.ietf-sipcore-callinfo-rcd], format 289 of the jCard and properties used should follow the normative usage 290 and formatting rules and procedures. The "jcl" key is optional. If 291 included, this key MUST only be included once in the "rcd" JSON 292 object and MUST NOT be included if there is a "jcd" key included. 293 The "jcd" and "jcl" keys MUST be used mutually exclusively. 295 5.1.4. "rcdi" RCD integrity Claim 297 The "rcdi" claim is an optional claim that SHOULD be included if the 298 application requires integrity to be applied to the content of the 299 "rcd" claim and if included MUST be included only once with a 300 corresponding "rcd" claim. The value of the "rcdi" key pair should 301 contain a string that is defined as follows. 303 The first part of the string should define the crypto algorithm used 304 to generate the digest. For RCD, implementations MUST support the 305 following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA- 306 256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic 307 hash functions defined by the NIST. Implementations MAY support 308 additional algorithms, but MUST NOT support known weak algorithms 309 such as MD5 or SHA-1. In the future, the list of algorithms may re- 310 evaluated based on security best practices. The algorithms MUST be 311 represented in the text by "sha256", "sha384", or "sha512". The 312 character following the algorithm string MUST be a minus character, 313 "-". The subsequent characters MUST be the base64 encoded digest of 314 a canonicalized and concatenated string based on the "rcd" claim and 315 the URLs contained in the claim. The details of the creation of this 316 string are defined in the next section. 318 Example: 319 "rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52" 321 5.1.5. Creation of the "rcd" digest 323 In order to facilitate proper verification of the digest and whether 324 the "rcd" content was modified, the input to the digest must be 325 completely deterministic at three points in the process. First, at 326 the certification point where the content is evaluated to conform to 327 the application policy and the JWT Claim Constraints is applied to 328 the certificate containing the digest. Second, when the call is 329 signed at the Authentication Service, there may be a local policy to 330 verify that the provided "rcd" claim corresponds to the digest. 331 Third, when the "rcd" data is verified at the Verification Service, 332 it MUST verify the digest by constructing the "rcd" input digest 333 string. 335 The procedures for the creation of the "rcd" input digest string is 336 as follows. 338 1. Arrange the keys in the "rcd" claim value to be in lexicographic 339 order. 341 2. Serialize the resulting "rcd" claim value JSON object to remove 342 all white space and line breaks. The procedures of this 343 deterministic JSON serialization is defined in [RFC8225], 344 Section 9. 346 3. Identify, in order of where they appear in the serialized string, 347 all of the URLs referencing external resource files. 349 4. Construct the "rcd" input string by first inserting the 350 serialized "rcd" claim value. 352 5. If there is at least one URL identified, insert a semicolon 353 character at the end of the "rcd" serialized string. 355 6. Follow the semicolon with the Base64 encoded contents of resource 356 file referenced by the first URL. 358 7. Repeat steps 5 and 6 for any additionally identified 359 corresponding URLs including URLs contained in resources 360 referenced by other URLs. When or if these nested URLs occur in 361 the contents referred to by a parent URL, the insertion of the 362 Base64 encoded contents should be included for all child URLs 363 before moving to any subsequent parent URL. 365 Once the input serialized string has been created, use this string to 366 create the base64 encoded digest output that can be inserted into the 367 "rcdi" claim as discussed in the last section. 369 Example "rcd" claim with URL: 370 "rcd": { "nam" : "James Bond", 371 "jcl" : "https://example.org/james_bond.json" 372 } 374 Example "rcd" input digest string (with line breaks for readability): 375 {"nam":"James Bond","jcl":"https://example.org/james_bond.json"}; 376 ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3 378 Example "rcdi" claim: 379 "rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M" 381 5.1.6. JWT Constraint for "rcdi" claim 383 Once both the contents of the "rcd" claim is certified and the 384 construction of the "rcdi" claim is complete, the "rcdi" digest is 385 linked to the STIR certificate associated with the signature in the 386 PASSporT via JWT Claim Constraints as defined in [RFC8226] Section 8. 388 The certificate JWT Claims Constraint MUST include both of the 389 following: 391 o a "mustInclude" for the "rcd" claim 393 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 394 to the created "rcdi" claim value string. 396 The "permitedValues" for the "rcdi" claim may contain multiple 397 entries, to support the case where the certificate holder is 398 authorized to use different sets of rich call data. 400 5.2. PASSporT "crn" claim - Call Reason 402 This specification defines a new JSON Web Token claim for "crn", Call 403 Reason, the value of which is a single string or object that can 404 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 405 corresponding to the "reason" parameter for the Call-Info header. 406 This claim is optional. 408 Example "crn" claim with "rcd": 409 "rcd": { "nam" : "James Bond", 410 "jcl" : "https://example.org/james_bond.json" 411 }, 412 "crn" : "For your ears only" 414 5.2.1. JWT Constraint for "cdn" claim 416 The integrity of the "crn" claim can optionally be protected by the 417 authoritative certificate creator using JWT Constraints in the 418 certificate. 420 6. "rcd" and "crn" Claims Usage 422 Either the "rcd" or "crn" claim may appear in any PASSporT claims 423 object as an optional element. The creator of a PASSporT MAY also 424 add a "ppt" value of "rcd" to the header of a PASSporT as well, in 425 which case the PASSporT claims MUST contain either a "rcd" or "crn" 426 claim, and any entities verifying the PASSporT object will be 427 required to understand the "ppt" extension in order to process the 428 PASSporT in question. A PASSporT header with the "ppt" included will 429 look as follows: 431 { "typ":"passport", 432 "ppt":"rcd", 433 "alg":"ES256", 434 "x5u":"https://www.example.com/cert.cer" } 436 The PASSporT claims object will then contain the "rcd" key with its 437 corresponding value. The value of "rcd" is an array of JSON objects, 438 of which one, the "nam" object, is mandatory. The key syntax of 439 "nam" follows the display-name ABNF given in [RFC3261]. 441 After the header and claims PASSporT objects have been constructed, 442 their signature is generated normally per the guidance in [RFC8225]. 444 6.1. Example "rcd" PASSporTs 446 An example of a "nam" only PASSporT claims obejct is shown next (with 447 line breaks for readability only). 449 { "orig":{"tn":"12025551000"}, 450 "dest":{"tn":"12025551001"}, 451 "iat":1443208345, 452 "rcd":{"nam":"James Bond"} } 454 An example of a "nam" only PASSporT claims object with an "rcdi" 455 claim is shown next (with line breaks for readability only). 457 { "orig":{"tn":"12025551000"}, 458 "dest":{"tn":"12025551001"}, 459 "iat":1443208345, 460 "rcd":{"nam":"James Bond"} 461 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52" 462 } 464 An example of a PASSporT claims object that includes the "jcd" which 465 is optional, but will also include the mandatory "nam" object is 466 shown next (with line breaks for readability only). 468 { "orig":{"tn":"12025551000"}, 469 "dest":{"tn":"12155551001"}, 470 "iat":1443208345, 471 "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text", 472 "4.0"], 473 ["fn",{},"text", "James Bond"], 474 ["n",{},"text",["Bond","James","","","Mr."]], 475 ["adr",{"type":"work"},"text", 476 ["","","3100 Massachusetts Avenue NW","Washington","DC", 477 "20008","USA"] 478 ], 479 ["email",{},"text","007@mi6-hq.com"], 480 ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", 481 "tel:+1-202-555-1000"], 482 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], 483 ["bday",{},"date","19241116"], 484 ["logo",{},"uri", 485 "https://upload.wikimedia.org/wikipedia/en/c/c5 486 /Fleming007impression.jpg" 487 ]]]}} 489 In an example PASSporT where a jCard is linked via HTTPS URL and 490 "jcl" a jCard file served at a particular URL will be created. 492 An example jCard JSON file is shown as follows: 494 ["vcard", 495 [ 496 ["version", {}, "text", "4.0"], 497 ["fn", {}, "text", "James Bond"], 498 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 499 ["adr", {"type":"work"}, "text", 500 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", 501 "20008", "USA"] 502 ], 503 ["email", {}, "text", "007@mi6-hq.com"], 504 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, 505 "uri", "tel:+1-202-555-1000"], 506 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 507 ["bday", {}, "date", "19241116"] 508 ["logo", {}, "uri", 509 "https://upload.wikimedia.org/wikipedia/en/c/c5 510 /Fleming007impression.jpg"] 511 ] 512 ] 514 If that jCard is hosted at the example address of 515 "https://example.org/james_bond.json", the corresponding PASSporT 516 claims object would be as follows (with line breaks for readability 517 only): 519 { "orig":{"tn":"12025551000"}, 520 "dest":{"tn":"12155551001"}, 521 "iat":1443208345, 522 "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} 523 } 525 If we were to add a "rcdi" integrity claim to the last example, the 526 corresponding PASSporT claims object would be as follows (with line 527 breaks for readability only): 529 { "orig":{"tn":"12025551000"}, 530 "dest":{"tn":"12155551001"}, 531 "iat":1443208345, 532 "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} 533 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm" 534 } 536 7. Compact form of "rcd" PASSporT 538 7.1. Compact form of the "rcd" PASSporT claim 540 Compact form of an "rcd" PASSporT claim has some restrictions but 541 mainly follows standard PASSporT compact form procedures. For re- 542 construction of the "nam" claim the string for the display-name in 543 the From header field. For re-construction of the "jcl", the Call- 544 Info header as with purpose "jcard" defined in 545 [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be 546 used as part of compact form. 548 7.2. Compact form of the "rcdi" PASSporT claim 550 Compact form of an "rcdi" PASSPorT claim shall be re-constructed 551 following the same "rcdi" defined digest procedures in this document 552 of all of the content and referenced URI content once downloaded. 554 7.3. Compact form of the "crn" PASSporT claim 556 Compact form of a "crn" PASSporT claim shall be re-constructed using 557 the "reason" parameter of a Call-Info header as defined by 558 [I-D.ietf-sipcore-callinfo-rcd]. 560 8. Further Information Associated with Callers 562 Beyond naming information and the information that can be contained 563 in a jCard [RFC7095] object, there may be additional human-readable 564 information about the calling party that should be rendered to the 565 end user in order to help the called party decide whether or not to 566 pick up the phone. This is not limited to information about the 567 caller, but includes information about the call itself, which may 568 derive from analytics that determine based on call patterns or 569 similar data if the call is likely to be one the called party wants 570 to receive. Such data could include: 572 o information related to the location of the caller, or 574 o any organizations or institutions that the caller is associated 575 with, or even categories of institutions (is this a government 576 agency, or a bank, or what have you), or 578 o hyperlinks to images, such as logos or pictures of faces, or to 579 similar external profile information, or 581 o information that will be processed by an application before 582 rendering it to a user, like social networking data that shows 583 that an unknown caller is a friend-of-a-friend, or reputation 584 scores derived from crowdsourcing, or confidence scores based on 585 broader analytics about the caller and callee. 587 All of these data elements would benefit from the secure attestations 588 provided by the STIR and PASSporT frameworks. A new IANA registry 589 has been defined to hold potential values of the "rcd" array; see 590 Section 14.3. Specific extensions to the "rcd" PASSporT claim are 591 left for future specification. 593 While in the traditional telephone network, the business relationship 594 between calling customers and their telephone service providers is 595 the ultimate root of information about a calling party's name, some 596 other forms of data like crowdsourced reputation scores might derive 597 from third parties. It is more likely that when those elements are 598 present, they will be in a third-party "rcd" PASSporT. 600 9. Third-Party Uses 602 While rich data about the call can be provided by an originating 603 authentication service, an intermediary in the call path could also 604 acquire rich call data by querying a third-party service. Such a 605 service effectively acts as a STIR Authentication Service, generating 606 its own PASSporT, and that PASSporT could be attached to a SIP call 607 by either the originating or terminating side. This third-party 608 PASSporT attests information about the calling number, rather than 609 the call or caller itself, and as such its RCD MUST NOT be used when 610 a call lacks a first-party PASSporT that assures verification 611 services that the calling party number is not spoofed. It is 612 intended to be used in cases when the originating side does not 613 supply a display-name for the caller, so instead some entity in the 614 call path invokes a third-party service to provide rich caller data 615 for a call. 617 In telephone operations today, a third-party information service is 618 commonly queried with the calling party's number in order to learn 619 the name of the calling party, and potentially other helpful 620 information could also be passed over that interface. The value of 621 using a PASSporT to convey this information from third parties lies 622 largely in the preservation of the original authority's signature 623 over the data, and the potential for the PASSporT to be conveyed from 624 intermediaries to endpoint devices. Effectively, these use cases 625 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 626 manner in which third-party services are discovered is outside the 627 scope of this document. 629 An intermediary use case might look as follows: a SIP INVITE carries 630 a display name in its From header field value and an initial PASSporT 631 object without the "rcd" claim. When the a terminating verification 632 service implemented at a SIP proxy server receives this request, and 633 determines that the signature is valid, it might query a third-party 634 service that maps telephone numbers to calling party names. Upon 635 receiving the PASSport in a response from that third-party service, 636 the terminating side could add a new Identity header field to the 637 request for the "rcd" PASSporT object provided by the third-party 638 service. It would then forward the INVITE to the terminating user 639 agent. If the display name in the "rcd" PASSporT object matches the 640 display name in the INVITE, then the name would presumably be 641 rendered to the end user by the terminating user agent. 643 A very similar flow could be followed by an intermediary closer to 644 the origination of the call. Presumably such a service could be 645 implemented at an originating network in order to decouple the 646 systems that sign for calling party numbers from the systems that 647 provide rich data about calls. 649 In an alternative use case, the terminating user agent might query a 650 third-party service. In this case, no new Identity header field 651 would be generated, though the terminating user agent might receive a 652 PASSporT object in return from the third-party service, and use the 653 "rcd" field in the object as a calling name to render to users while 654 alerting. 656 9.1. Signing as a Third Party 658 A third-party PASSporT, which contains such an "iss" element, will 659 necessarily be signed with credentials that do not have authority 660 over the identity that appears in the "orig" element of the PASSporT 661 claims. The presence of "iss" signifies that a different category of 662 credential is being used to sign a PASSporT than the [RFC8226] 663 certificates used to sign STIR calls; it is instead a certificate 664 that identifies the source of the "rcd" data. How those credentials 665 are issued and managed is outside the scope of this specification; 666 the value of "iss" however MUST reflect the Subject Name field of the 667 certificate used to sign a third-party PASSporT. Relying parties in 668 STIR have always been left to make their own authorization decisions 669 about whether or not the trust the signers of PASSporTs, and in the 670 third-party case, where an entity has explicitly queried a service to 671 acquire the PASSporT object, it may be some external trust or 672 business relationship that induces the relying party to trust a 673 PASSporT. 675 An example of a Third Party issued PASSporT claims object is as 676 follows. 678 { "orig":{"tn":"12025551000"}, 679 "dest":{"tn":"12025551001"}, 680 "iat":1443208345, 681 "iss":"Example, Inc.", 682 "rcd":{"nam":"James Bond"} } 684 10. Levels of Assurance 686 As "rcd" can be provided by either first or third parties, relying 687 parties could benefit from an additional claim that indicates the 688 relationship of the attesting party to the caller. Even in first 689 party cases, this admits of some complexity: the Communications 690 Service Provider (CSP) to which a number was assigned might in turn 691 delegate the number to a reseller, who would then sell the number to 692 an enterprise, in which case the CSP might have little insight into 693 the caller's name. In third party cases, a caller's name could 694 derive from any number of data sources, on a spectrum between public 695 data scraped from web searches to a direct business relationship to 696 the caller. As multiple PASSporTs can be associated with the same 697 call, potentially a verification service could receive attestations 698 of the caller name from multiple sources, which have different levels 699 of granularity or accuracy. Therefore, PASSporTs that carry "rcd" 700 data SHOULD also carry an indication of the relationship of the 701 generator of the PASSporT to the caller. As stated in the previous 702 section, the use of "iss" MUST reflect the Organization (O) field of 703 the certificate used to sign a third-party PASSporT to represent that 704 relationship. 706 11. Using "rcd" in SIP 708 This section specifies SIP-specific usage for the "rcd" claim in 709 PASSporT, and in the SIP Identity header field value. Other using 710 protocols of PASSporT may define their own usages for the "rcd" 711 claim. 713 11.1. Authentication Service Behavior 715 An authentication service creating a PASSporT containing a "rcd" 716 claim MAY include a "ppt" for "rcd" or not. Third-party 717 authentication services following the behavior in Section 9.1 MUST 718 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 719 SIP authentication services MUST add a "ppt" parameter to the 720 Identity header containing that PASSporT with a value of "rcd". The 721 resulting Identity header might look as follows: 723 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 724 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0 725 Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 726 info=;alg=ES256;ppt="rcd" 728 This specification assumes that by default, a SIP authentication 729 service will derive the value of "rcd", specifically only for the 730 "nam" key value, from the display-name component of the From header 731 field value of the request, alternatively for some calls this may 732 come from the P-Asserted-ID header. It is however a matter of 733 authentication service policy to decide how it populates the value of 734 "rcd" and "nam" key, which MAY also derive from other fields in the 735 request, from customer profile data, or from access to external 736 services. If the authentication service generates a PASSporT object 737 containing "rcd" with a value that is not equivalent to the From 738 header field display-name value, it MUST use the full form of the 739 PASSporT object in SIP. 741 11.2. Verification Service Behavior 743 [RFC8224] Section 6.2 Step 5 requires that specifications defining 744 "ppt" values describe any additional verifier behavior. The behavior 745 specified for the "ppt" values of "rcd" is as follows. If the 746 PASSporT is in compact form, then the verification service SHOULD 747 extract the display-name from the From header field value, if any, 748 and use that as the value for the "nam" key when it recomputes the 749 header and claims of the PASSporT object. Optionally, if there 750 exists a Call-Info header field as defined in 752 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 753 determine the "jcd" key when it recomputes the header and claims of 754 the PASSporT object. If the signature validates over the recomputed 755 object, then the verification should be considered successful. 757 However, if the PASSport is in full form with a "ppt" value of "rcd", 758 then the verification service MUST extract the value associated with 759 the "rcd" "nam" key in the object. If the signature validates, then 760 the verification service can use the value of the "rcd" "nam" key as 761 the display name of calling party, which would in turn be rendered to 762 alerted users or otherwise leveraged in accordance with local policy. 763 This will allow SIP networks that convey the display name through a 764 field other than the From header field to interoperate with this 765 specification. Similarly, the "jcd" or linked "jcl" jcard 766 information and "crn" can be optionally, based on local policy for 767 devices that support it, used to populate a Call-Info header field 768 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 770 The third-party "rcd" PASSporT cases presents some new challenges, as 771 an attacker could attempt to cut-and-paste such a third-party 772 PASSporT into a SIP request in an effort to get the terminating user 773 agent to render the display name or confidence values it contains to 774 a call that should have no such assurance. A third-party "rcd" 775 PASSporT provides no assurance that the calling party number has not 776 been spoofed: if it is carried in a SIP request, for example, then 777 some other PASSporT in another Identity header field value would have 778 to carry a PASSporT attesting that. A verification service MUST 779 determine that the calling party number shown in the "orig" of the 780 "rcd" PASSporT corresponds to the calling party number of the call it 781 has received, and that the "iat" field of the "rcd" PASSporT is 782 within the date interval that the verification service would 783 ordinarily accept for a PASSporT. 785 Verification services may alter their authorization policies for the 786 credentials accepted to sign PASSporTs when third parties generate 787 PASSporT objects, per Section 9.1. This may include accepting a 788 valid signature over a PASSporT even if it is signed with a 789 credential that does not attest authority over the identity in the 790 "orig" claim of the PASSporT, provided that the verification service 791 has some other reason to trust the signer. No further guidance on 792 verification service authorization policy is given here. 794 The behavior of a SIP UAS upon receiving an INVITE containing a 795 PASSporT object with a "rcd" claim will largely remain a matter of 796 implementation policy. In most cases, implementations would render 797 this calling party name information to the user while alerting. Any 798 user interface additions to express confidence in the veracity of 799 this information are outside the scope of this specification. 801 12. Using "rcd" as additional claims to other PASSporT extensions 803 Rich Call Data, including calling name information, for example, is 804 often data that is additive data to the personal communications 805 information defined in the core PASSporT data required to support the 806 security properties defined in [RFC8225]. For cases where the entity 807 that is originating the personal communications and additionally is 808 supporting the authentication service and also is the authority of 809 the Rich Call Data, rather than creating multiple identity headers 810 with multiple PASSporT extensions or defining multiple combinations 811 and permutations of PASSporT extension definitions, the 812 authentication service can alternatively directly add the "rcd" 813 claims to the PASSporT it is creating, whether it is constructed with 814 a PASSporT extension or not. 816 12.1. Procedures for applying "rcd" as claims only 818 For a given PASSporT using some other extension than "rcd", the 819 Authentication Service MAY additionally include the "rcd" claim as 820 defined in this document. This would result in a set of claims that 821 correspond to the original intended extension with the addition of 822 the "rcd" claim. 824 The Verification service that receives the PASSporT, if it supports 825 this specification and chooses to, should interpret the "rcd" claim 826 as simply just an additional claim intended to deliver and/or 827 validate delivered Rich Call Data. 829 12.2. Example for applying "rcd" as claims only 831 In the case of [RFC8588] which is the PASSporT extension supporting 832 the SHAKEN specification [ATIS-1000074], a common case for an 833 Authentication service to co-exist in a CSP network along with the 834 authority over the calling name used for the call. Rather than 835 require two identity headers, the CSP Authentication Service can 836 apply both the SHAKEN PASSporT claims and extension and simply add 837 the "rcd" required claims defined in this document. 839 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 840 claims would be as follows: 842 Protected Header 843 { 844 "alg":"ES256", 845 "typ":"passport", 846 "ppt":"shaken", 847 "x5u":"https://cert.example.org/passport.cer" 848 } 849 Payload 850 { 851 "attest":"A", 852 "dest":{"tn":["12025551001"]}, 853 "iat":1443208345, 854 "orig":{"tn":"12025551000"}, 855 "origid":"123e4567-e89b-12d3-a456-426655440000", 856 "rcd":{"nam":"James Bond"} 857 } 859 A Verification Service that supports "rcd" and "shaken" PASSporT 860 extensions will be able to receive the above PASSporT and interpret 861 both the "shaken" claims as well as the "rcd" defined claim. 863 If the Verification Service only understands the "shaken" extension 864 claims but doesn't support "rcd", the "rcd" can simply be ignored and 865 disregarded. 867 13. Acknowledgements 869 We would like to thank David Hancock, Robert Sparks, Russ Housley, 870 and Eric Burger for helpful suggestions and comments. 872 14. IANA Considerations 874 14.1. JSON Web Token Claim 876 This specification requests that the IANA add three new claims to the 877 JSON Web Token Claims registry as defined in [RFC7519]. 879 Claim Name: "rcd" 881 Claim Description: Rich Call Data Information 883 Change Controller: IESG 885 Specification Document(s): [RFCThis] 887 Claim Name: "rcdi" 889 Claim Description: Rich Call Data Integrity Information 890 Change Controller: IESG 892 Specification Document(s): [RFCThis] 894 Claim Name: "crn" 896 Claim Description: Call Reason 898 Change Controller: IESG 900 Specification Document(s): [RFCThis] 902 14.2. PASSporT Types 904 This specification requests that the IANA add a new entry to the 905 PASSporT Types registry for the type "rcd" which is specified in 906 [RFCThis]. 908 14.3. PASSporT RCD Types 910 This document requests that the IANA create a new registry for 911 PASSporT RCD types. Registration of new PASSporT RCD types shall be 912 under the Specification Required policy. 914 This registry is to be initially populated with three values, "nam", 915 "jcd", and "jcl", which are specified in [RFCThis]. 917 15. Security Considerations 919 Revealing information such as the name, location, and affiliation of 920 a person necessarily entails certain privacy risks. Baseline 921 PASSporT has no particular confidentiality requirement, as the 922 information it signs over in a using protocol like SIP is all 923 information that SIP carries in the clear anyway. Transport-level 924 security can hide those SIP fields from eavesdroppers, and the same 925 confidentiality mechanisms would protect any PASSporT(s) carried in 926 SIP. 928 16. References 930 16.1. Normative References 932 [I-D.ietf-sipcore-callinfo-rcd] 933 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 934 Rich Call Data", draft-ietf-sipcore-callinfo-rcd-00 (work 935 in progress), November 2020. 937 [I-D.ietf-stir-oob] 938 Rescorla, E. and J. Peterson, "STIR Out-of-Band 939 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 940 in progress), March 2020. 942 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 943 A., Peterson, J., Sparks, R., Handley, M., and E. 944 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 945 DOI 10.17487/RFC3261, June 2002, 946 . 948 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 949 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 950 DOI 10.17487/RFC6919, April 2013, 951 . 953 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 954 DOI 10.17487/RFC7095, January 2014, 955 . 957 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 958 Telephone Identity Problem Statement and Requirements", 959 RFC 7340, DOI 10.17487/RFC7340, September 2014, 960 . 962 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 963 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 964 . 966 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 967 "Authenticated Identity Management in the Session 968 Initiation Protocol (SIP)", RFC 8224, 969 DOI 10.17487/RFC8224, February 2018, 970 . 972 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 973 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 974 . 976 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 977 Credentials: Certificates", RFC 8226, 978 DOI 10.17487/RFC8226, February 2018, 979 . 981 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 982 (PaSSporT) Extension for Signature-based Handling of 983 Asserted information using toKENs (SHAKEN)", RFC 8588, 984 DOI 10.17487/RFC8588, May 2019, 985 . 987 16.2. Informative References 989 [ATIS-1000074] 990 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 991 of Asserted information using toKENs (SHAKEN) 992 ", January 2017. 995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 996 Requirement Levels", BCP 14, RFC 2119, 997 DOI 10.17487/RFC2119, March 1997, 998 . 1000 Authors' Addresses 1002 Jon Peterson 1003 Neustar Inc. 1004 1800 Sutter St Suite 570 1005 Concord, CA 94520 1006 US 1008 Email: jon.peterson@neustar.biz 1010 Chris Wendt 1011 Comcast 1012 Comcast Technology Center 1013 Philadelphia, PA 19103 1014 USA 1016 Email: chris-ietf@chriswendt.net