idnits 2.17.1 draft-ietf-stir-passport-rcd-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 16, 2020) is 1255 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 916, 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') ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 4 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 20, 2021 Comcast 6 November 16, 2020 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-09 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 20, 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 . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 10 78 6. "rcd" and "crn" Claims Usage . . . . . . . . . . . . . . . . 10 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 . . . . . . . . 13 82 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 13 83 7.3. Compact form of the "crn" PASSporT claim . . . . . . . . 13 84 8. Further Information Associated with Callers . . . . . . . . . 13 85 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 15 87 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 16 88 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 16 89 11.1. Authentication Service Behavior . . . . . . . . . . . . 16 90 11.2. Verification Service Behavior . . . . . . . . . . . . . 17 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 . . . . . . . 19 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 95 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 20 97 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 20 98 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 20 99 15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 16.1. Normative References . . . . . . . . . . . . . . . . . . 21 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 alternatively from the P-Asserted-Identity header field 257 value, or a similar field in other PASSporT using protocols. This 258 key MUST be included once and MUST be included as part of the "rcd" 259 claim value JSON object. If there is no string associated with a 260 display name, the claim value SHOULD then be an empty string. 262 5.1.2. "jcd" key 264 The "jcd" key value is defined to contain a value of a jCard 265 [RFC7095] JSON object. This jCard object is intended to represent 266 and derives from the Call-Info header field value defined in 267 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 268 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 269 properties used should follow the normative usage and formatting 270 rules and procedures. It is an extensible object where the calling 271 party can provide both the standard types of information defined in 272 jCard or can use the built-in extensibility of the jCard 273 specification to add additional information. The "jcd" is optional. 274 If included, this key MUST only be included once in the "rcd" JSON 275 object and SHOULD NOT be included if there is a "jcl" key included. 276 The "jcd" and "jcl" keys should be mutually exclusive. 278 Note: even though we refer to [I-D.ietf-sipcore-callinfo-rcd] as the 279 definition of the jcard properties for usage in a "rcd" PASSporT, 280 other protocols can be adapted for use of "jcd" (or similarly "jcl" 281 below) key beyond SIP and Call-Info. 283 5.1.3. "jcl" key 285 The "jcl" key value is defined to contain a HTTPS URL that refers the 286 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 287 web server. The web server MUST use the MIME media type for JSON 288 text as application/json with a default encoding of UTF-8 [RFC4627]. 289 This link may derive from the Call-Info header field value defined in 290 [I-D.ietf-sipcore-callinfo-rcd] with a type of "jcard". As also 291 defined in [I-D.ietf-sipcore-callinfo-rcd], format of the jCard and 292 properties used should follow the normative usage and formatting 293 rules and procedures. The "jcl" key is optional. If included, this 294 key MUST only be included once in the "rcd" JSON object and MUST NOT 295 be included if there is a "jcd" key included. The "jcd" and "jcl" 296 keys MUST be used mutually exclusively. 298 5.1.4. "rcdi" RCD integrity Claim 300 The "rcdi" claim is an optional claim that SHOULD be included if the 301 application requires integrity to be applied to the content of the 302 "rcd" claim and if included MUST be included only once with a 303 corresponding "rcd" claim. The value of the "rcdi" key pair should 304 contain a string that is defined as follows. 306 The first part of the string should define the crypto algorithm used 307 to generate the digest. For RCD, implementations MUST support the 308 following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA- 309 256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic 310 hash functions defined by the NIST. Implementations MAY support 311 additional algorithms, but MUST NOT support known weak algorithms 312 such as MD5 or SHA-1. In the future, the list of algorithms may re- 313 evaluated based on security best practices. The algorithms MUST be 314 represented in the text by "sha256", "sha384", or "sha512". The 315 character following the algorithm string MUST be a minus character, 316 "-". The subsequent characters MUST be the base64 encoded digest of 317 a canonicalized and concatenated string based on the "rcd" claim and 318 the URLs contained in the claim. The details of the creation of this 319 string are defined in the next section. 321 Example: 322 "rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52" 324 5.1.5. Creation of the "rcd" digest 326 In order to facilitate proper verification of the digest and whether 327 the "rcd" content was modified, the input to the digest must be 328 completely deterministic at three points in the process. First, at 329 the certification point where the content is evaluated to conform to 330 the application policy and the JWT Claim Constraints is applied to 331 the certificate containing the digest. Second, when the call is 332 signed at the Authentication Service, there may be a local policy to 333 verify that the provided "rcd" claim corresponds to the digest. 334 Third, when the "rcd" data is verified at the Verification Service, 335 it MUST verify the digest by constructing the "rcd" input digest 336 string. 338 The procedures for the creation of the "rcd" input digest string is 339 as follows. 341 1. Arrange the keys in the "rcd" claim value to be in lexicographic 342 order. 344 2. Serialize the resulting "rcd" claim value JSON object to remove 345 all white space and line breaks. The procedures of this 346 deterministic JSON serialization is defined in [RFC8225], 347 Section 9. 349 3. Identify, in order of where they appear in the serialized string, 350 all of the URLs referencing external resource files. 352 4. Construct the "rcd" input string by first inserting the 353 serialized "rcd" claim value. 355 5. If there is at least one URL identified, insert a semicolon 356 character at the end of the "rcd" serialized string. 358 6. Follow the semicolon with the Base64 encoded contents of resource 359 file referenced by the first URL. 361 7. Repeat steps 5 and 6 for any additionally identified 362 corresponding URLs including URLs contained in resources 363 referenced by other URLs. When or if these nested URLs occur in 364 the contents referred to by a parent URL, the insertion of the 365 Base64 encoded contents should be included for all child URLs 366 before moving to any subsequent parent URL. 368 Once the input serialized string has been created, use this string to 369 create the base64 encoded digest output that can be inserted into the 370 "rcdi" claim as discussed in the last section. 372 Example "rcd" claim with URL: 373 "rcd": { "nam" : "James Bond", 374 "jcl" : "https://example.org/james_bond.json" 375 } 377 Example "rcd" input digest string (with line breaks for readability): 378 {"nam":"James Bond","jcl":"https://example.org/james_bond.json"}; 379 ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3 381 Example "rcdi" claim: 382 "rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M" 384 5.1.6. JWT Constraint for "rcdi" claim 386 Once both the contents of the "rcd" claim is certified and the 387 construction of the "rcdi" claim is complete, the "rcdi" digest is 388 linked to the STIR certificate associated with the signature in the 389 PASSporT via JWT Claim Constraints as defined in [RFC8226] Section 8. 391 The certificate JWT Claims Constraint MUST include both of the 392 following: 394 o a "mustInclude" for the "rcd" claim 396 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 397 to the created "rcdi" claim value string. 399 The "permitedValues" for the "rcdi" claim may contain multiple 400 entries, to support the case where the certificate holder is 401 authorized to use different sets of rich call data. 403 5.2. PASSporT "crn" claim - Call Reason 405 This specification defines a new JSON Web Token claim for "crn", Call 406 Reason, the value of which is a single string or object that can 407 contains information as defined in [I-D.ietf-sipcore-callinfo-rcd] 408 corresponding to the "reason" parameter for the Call-Info header. 409 This claim is optional. 411 Example "crn" claim with "rcd": 412 "rcd": { "nam" : "James Bond", 413 "jcl" : "https://example.org/james_bond.json" 414 }, 415 "crn" : "For your ears only" 417 5.2.1. JWT Constraint for "cdn" claim 419 The integrity of the "crn" claim can optionally be protected by the 420 authoritative certificate creator using JWT Constraints in the 421 certificate. 423 6. "rcd" and "crn" Claims Usage 425 Either the "rcd" or "crn" claim may appear in any PASSporT claims 426 object as an optional element. The creator of a PASSporT MAY also 427 add a "ppt" value of "rcd" to the header of a PASSporT as well, in 428 which case the PASSporT claims MUST contain either a "rcd" or "crn" 429 claim, and any entities verifying the PASSporT object will be 430 required to understand the "ppt" extension in order to process the 431 PASSporT in question. A PASSporT header with the "ppt" included will 432 look as follows: 434 { "typ":"passport", 435 "ppt":"rcd", 436 "alg":"ES256", 437 "x5u":"https://www.example.com/cert.cer" } 439 The PASSporT claims object will then contain the "rcd" key with its 440 corresponding value. The value of "rcd" is an array of JSON objects, 441 of which one, the "nam" object, is mandatory. The key syntax of 442 "nam" follows the display-name ABNF given in [RFC3261]. 444 After the header and claims PASSporT objects have been constructed, 445 their signature is generated normally per the guidance in [RFC8225]. 447 6.1. Example "rcd" PASSporTs 449 An example of a "nam" only PASSporT claims obejct is shown next (with 450 line breaks for readability only). 452 { "orig":{"tn":"12025551000"}, 453 "dest":{"tn":["12025551001"]}, 454 "iat":1443208345, 455 "rcd":{"nam":"James Bond"} } 457 An example of a "nam" only PASSporT claims object with an "rcdi" 458 claim is shown next (with line breaks for readability only). 460 { "orig":{"tn":"12025551000"}, 461 "dest":{"tn":["12025551001"]}, 462 "iat":1443208345, 463 "rcd":{"nam":"James Bond"} 464 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52" 465 } 467 An example of a PASSporT claims object that includes the "jcd" which 468 is optional, but will also include the mandatory "nam" object is 469 shown next (with line breaks for readability only). 471 { "orig":{"tn":"12025551000"}, 472 "dest":{"tn":["12155551001"]}, 473 "iat":1443208345, 474 "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text", 475 "4.0"], 476 ["fn",{},"text", "James Bond"], 477 ["n",{},"text",["Bond","James","","","Mr."]], 478 ["adr",{"type":"work"},"text", 479 ["","","3100 Massachusetts Avenue NW","Washington","DC", 480 "20008","USA"] 481 ], 482 ["email",{},"text","007@mi6-hq.com"], 483 ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", 484 "tel:+1-202-555-1000"], 485 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], 486 ["bday",{},"date","19241116"], 487 ["logo",{},"uri", 488 "https://upload.wikimedia.org/wikipedia/en/c/c5 489 /Fleming007impression.jpg" 490 ]]]}} 492 In an example PASSporT where a jCard is linked via HTTPS URL and 493 "jcl" a jCard file served at a particular URL will be created. 495 An example jCard JSON file is shown as follows: 497 ["vcard", 498 [ 499 ["version", {}, "text", "4.0"], 500 ["fn", {}, "text", "James Bond"], 501 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 502 ["adr", {"type":"work"}, "text", 503 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", 504 "20008", "USA"] 505 ], 506 ["email", {}, "text", "007@mi6-hq.com"], 507 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, 508 "uri", "tel:+1-202-555-1000"], 509 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 510 ["bday", {}, "date", "19241116"] 511 ["logo", {}, "uri", 512 "https://upload.wikimedia.org/wikipedia/en/c/c5 513 /Fleming007impression.jpg"] 514 ] 515 ] 517 If that jCard is hosted at the example address of 518 "https://example.org/james_bond.json", the corresponding PASSporT 519 claims object would be as follows (with line breaks for readability 520 only): 522 { "orig":{"tn":"12025551000"}, 523 "dest":{"tn":["12155551001"]}, 524 "iat":1443208345, 525 "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} 526 } 528 If we were to add a "rcdi" integrity claim to the last example, the 529 corresponding PASSporT claims object would be as follows (with line 530 breaks for readability only): 532 { "orig":{"tn":"12025551000"}, 533 "dest":{"tn":["12155551001"]}, 534 "iat":1443208345, 535 "rcd":{"nam":"James Bond","jcl":"https://example.org/jb.json"} 536 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm" 537 } 539 7. Compact form of "rcd" PASSporT 540 7.1. Compact form of the "rcd" PASSporT claim 542 Compact form of an "rcd" PASSporT claim has some restrictions but 543 mainly follows standard PASSporT compact form procedures. For re- 544 construction of the "nam" claim the string for the display-name in 545 the From header field. For re-construction of the "jcl", the Call- 546 Info header as with purpose "jcard" defined in 547 [I-D.ietf-sipcore-callinfo-rcd] MUST be used. "jcd" claim MAY NOT be 548 used as part of compact form. 550 7.2. Compact form of the "rcdi" PASSporT claim 552 Compact form of an "rcdi" PASSPorT claim shall be re-constructed 553 following the same "rcdi" defined digest procedures in this document 554 of all of the content and referenced URI content once downloaded. 556 7.3. Compact form of the "crn" PASSporT claim 558 Compact form of a "crn" PASSporT claim shall be re-constructed using 559 the "reason" parameter of a Call-Info header as defined by 560 [I-D.ietf-sipcore-callinfo-rcd]. 562 8. Further Information Associated with Callers 564 Beyond naming information and the information that can be contained 565 in a jCard [RFC7095] object, there may be additional human-readable 566 information about the calling party that should be rendered to the 567 end user in order to help the called party decide whether or not to 568 pick up the phone. This is not limited to information about the 569 caller, but includes information about the call itself, which may 570 derive from analytics that determine based on call patterns or 571 similar data if the call is likely to be one the called party wants 572 to receive. Such data could include: 574 o information related to the location of the caller, or 576 o any organizations or institutions that the caller is associated 577 with, or even categories of institutions (is this a government 578 agency, or a bank, or what have you), or 580 o hyperlinks to images, such as logos or pictures of faces, or to 581 similar external profile information, or 583 o information that will be processed by an application before 584 rendering it to a user, like social networking data that shows 585 that an unknown caller is a friend-of-a-friend, or reputation 586 scores derived from crowdsourcing, or confidence scores based on 587 broader analytics about the caller and callee. 589 All of these data elements would benefit from the secure attestations 590 provided by the STIR and PASSporT frameworks. A new IANA registry 591 has been defined to hold potential values of the "rcd" array; see 592 Section 14.3. Specific extensions to the "rcd" PASSporT claim are 593 left for future specification. 595 While in the traditional telephone network, the business relationship 596 between calling customers and their telephone service providers is 597 the ultimate root of information about a calling party's name, some 598 other forms of data like crowdsourced reputation scores might derive 599 from third parties. It is more likely that when those elements are 600 present, they will be in a third-party "rcd" PASSporT. 602 9. Third-Party Uses 604 While rich data about the call can be provided by an originating 605 authentication service, an intermediary in the call path could also 606 acquire rich call data by querying a third-party service. Such a 607 service effectively acts as a STIR Authentication Service, generating 608 its own PASSporT, and that PASSporT could be attached to a SIP call 609 by either the originating or terminating side. This third-party 610 PASSporT attests information about the calling number, rather than 611 the call or caller itself, and as such its RCD MUST NOT be used when 612 a call lacks a first-party PASSporT that assures verification 613 services that the calling party number is not spoofed. It is 614 intended to be used in cases when the originating side does not 615 supply a display-name for the caller, so instead some entity in the 616 call path invokes a third-party service to provide rich caller data 617 for a call. 619 In telephone operations today, a third-party information service is 620 commonly queried with the calling party's number in order to learn 621 the name of the calling party, and potentially other helpful 622 information could also be passed over that interface. The value of 623 using a PASSporT to convey this information from third parties lies 624 largely in the preservation of the original authority's signature 625 over the data, and the potential for the PASSporT to be conveyed from 626 intermediaries to endpoint devices. Effectively, these use cases 627 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 628 manner in which third-party services are discovered is outside the 629 scope of this document. 631 An intermediary use case might look as follows: a SIP INVITE carries 632 a display name in its From header field value and an initial PASSporT 633 object without the "rcd" claim. When the a terminating verification 634 service implemented at a SIP proxy server receives this request, and 635 determines that the signature is valid, it might query a third-party 636 service that maps telephone numbers to calling party names. Upon 637 receiving the PASSport in a response from that third-party service, 638 the terminating side could add a new Identity header field to the 639 request for the "rcd" PASSporT object provided by the third-party 640 service. It would then forward the INVITE to the terminating user 641 agent. If the display name in the "rcd" PASSporT object matches the 642 display name in the INVITE, then the name would presumably be 643 rendered to the end user by the terminating user agent. 645 A very similar flow could be followed by an intermediary closer to 646 the origination of the call. Presumably such a service could be 647 implemented at an originating network in order to decouple the 648 systems that sign for calling party numbers from the systems that 649 provide rich data about calls. 651 In an alternative use case, the terminating user agent might query a 652 third-party service. In this case, no new Identity header field 653 would be generated, though the terminating user agent might receive a 654 PASSporT object in return from the third-party service, and use the 655 "rcd" field in the object as a calling name to render to users while 656 alerting. 658 9.1. Signing as a Third Party 660 A third-party PASSporT, which contains such an "iss" element, will 661 necessarily be signed with credentials that do not have authority 662 over the identity that appears in the "orig" element of the PASSporT 663 claims. The presence of "iss" signifies that a different category of 664 credential is being used to sign a PASSporT than the [RFC8226] 665 certificates used to sign STIR calls; it is instead a certificate 666 that identifies the source of the "rcd" data. How those credentials 667 are issued and managed is outside the scope of this specification; 668 the value of "iss" however MUST reflect the Subject Name field of the 669 certificate used to sign a third-party PASSporT. Relying parties in 670 STIR have always been left to make their own authorization decisions 671 about whether or not the trust the signers of PASSporTs, and in the 672 third-party case, where an entity has explicitly queried a service to 673 acquire the PASSporT object, it may be some external trust or 674 business relationship that induces the relying party to trust a 675 PASSporT. 677 An example of a Third Party issued PASSporT claims object is as 678 follows. 680 { "orig":{"tn":"12025551000"}, 681 "dest":{"tn":["12025551001"]}, 682 "iat":1443208345, 683 "iss":"Example, Inc.", 684 "rcd":{"nam":"James Bond"} } 686 10. Levels of Assurance 688 As "rcd" can be provided by either first or third parties, relying 689 parties could benefit from an additional claim that indicates the 690 relationship of the attesting party to the caller. Even in first 691 party cases, this admits of some complexity: the Communications 692 Service Provider (CSP) to which a number was assigned might in turn 693 delegate the number to a reseller, who would then sell the number to 694 an enterprise, in which case the CSP might have little insight into 695 the caller's name. In third party cases, a caller's name could 696 derive from any number of data sources, on a spectrum between public 697 data scraped from web searches to a direct business relationship to 698 the caller. As multiple PASSporTs can be associated with the same 699 call, potentially a verification service could receive attestations 700 of the caller name from multiple sources, which have different levels 701 of granularity or accuracy. Therefore, PASSporTs that carry "rcd" 702 data SHOULD also carry an indication of the relationship of the 703 generator of the PASSporT to the caller. As stated in the previous 704 section, the use of "iss" MUST reflect the Organization (O) field of 705 the certificate used to sign a third-party PASSporT to represent that 706 relationship. 708 11. Using "rcd" in SIP 710 This section specifies SIP-specific usage for the "rcd" claim in 711 PASSporT, and in the SIP Identity header field value. Other using 712 protocols of PASSporT may define their own usages for the "rcd" 713 claim. 715 11.1. Authentication Service Behavior 717 An authentication service creating a PASSporT containing a "rcd" 718 claim MAY include a "ppt" for "rcd" or not. Third-party 719 authentication services following the behavior in Section 9.1 MUST 720 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 721 SIP authentication services MUST add a "ppt" parameter to the 722 Identity header containing that PASSporT with a value of "rcd". The 723 resulting Identity header might look as follows: 725 Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9 726 dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt 727 w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 728 info=;alg=ES256;ppt=rcd 730 This specification assumes that by default, a SIP authentication 731 service will derive the value of "rcd", specifically only for the 732 "nam" key value, from the display-name component of the From header 733 field value of the request, alternatively for some calls this may 734 come from the P-Asserted-ID header. It is however a matter of 735 authentication service policy to decide how it populates the value of 736 "rcd" and "nam" key, which MAY also derive from other fields in the 737 request, from customer profile data, or from access to external 738 services. If the authentication service generates a PASSporT object 739 containing "rcd" with a value that is not equivalent to the From 740 header field display-name value, it MUST use the full form of the 741 PASSporT object in SIP. 743 11.2. Verification Service Behavior 745 [RFC8224] Section 6.2 Step 5 requires that specifications defining 746 "ppt" values describe any additional verifier behavior. The behavior 747 specified for the "ppt" values of "rcd" is as follows. If the 748 PASSporT is in compact form, then the verification service SHOULD 749 extract the display-name from the From header field value, if any, 750 and use that as the value for the "nam" key when it recomputes the 751 header and claims of the PASSporT object. Optionally, if there 752 exists a Call-Info header field as defined in 753 [I-D.ietf-sipcore-callinfo-rcd], the "jcard" value can be derived to 754 determine the "jcd" key when it recomputes the header and claims of 755 the PASSporT object. If the signature validates over the recomputed 756 object, then the verification should be considered successful. 758 However, if the PASSport is in full form with a "ppt" value of "rcd", 759 then the verification service MUST extract the value associated with 760 the "rcd" "nam" key in the object. If the signature validates, then 761 the verification service can use the value of the "rcd" "nam" key as 762 the display name of calling party, which would in turn be rendered to 763 alerted users or otherwise leveraged in accordance with local policy. 764 This will allow SIP networks that convey the display name through a 765 field other than the From header field to interoperate with this 766 specification. Similarly, the "jcd" or linked "jcl" jcard 767 information and "crn" can be optionally, based on local policy for 768 devices that support it, used to populate a Call-Info header field 769 following the format of [I-D.ietf-sipcore-callinfo-rcd]. 771 The third-party "rcd" PASSporT cases presents some new challenges, as 772 an attacker could attempt to cut-and-paste such a third-party 773 PASSporT into a SIP request in an effort to get the terminating user 774 agent to render the display name or confidence values it contains to 775 a call that should have no such assurance. A third-party "rcd" 776 PASSporT provides no assurance that the calling party number has not 777 been spoofed: if it is carried in a SIP request, for example, then 778 some other PASSporT in another Identity header field value would have 779 to carry a PASSporT attesting that. A verification service MUST 780 determine that the calling party number shown in the "orig" of the 781 "rcd" PASSporT corresponds to the calling party number of the call it 782 has received, and that the "iat" field of the "rcd" PASSporT is 783 within the date interval that the verification service would 784 ordinarily accept for a PASSporT. 786 Verification services may alter their authorization policies for the 787 credentials accepted to sign PASSporTs when third parties generate 788 PASSporT objects, per Section 9.1. This may include accepting a 789 valid signature over a PASSporT even if it is signed with a 790 credential that does not attest authority over the identity in the 791 "orig" claim of the PASSporT, provided that the verification service 792 has some other reason to trust the signer. No further guidance on 793 verification service authorization policy is given here. 795 The behavior of a SIP UAS upon receiving an INVITE containing a 796 PASSporT object with a "rcd" claim will largely remain a matter of 797 implementation policy. In most cases, implementations would render 798 this calling party name information to the user while alerting. Any 799 user interface additions to express confidence in the veracity of 800 this information are outside the scope of this specification. 802 12. Using "rcd" as additional claims to other PASSporT extensions 804 Rich Call Data, including calling name information, for example, is 805 often data that is additive data to the personal communications 806 information defined in the core PASSporT data required to support the 807 security properties defined in [RFC8225]. For cases where the entity 808 that is originating the personal communications and additionally is 809 supporting the authentication service and also is the authority of 810 the Rich Call Data, rather than creating multiple identity headers 811 with multiple PASSporT extensions or defining multiple combinations 812 and permutations of PASSporT extension definitions, the 813 authentication service can alternatively directly add the "rcd" 814 claims to the PASSporT it is creating, whether it is constructed with 815 a PASSporT extension or not. 817 12.1. Procedures for applying "rcd" as claims only 819 For a given PASSporT using some other extension than "rcd", the 820 Authentication Service MAY additionally include the "rcd" claim as 821 defined in this document. This would result in a set of claims that 822 correspond to the original intended extension with the addition of 823 the "rcd" claim. 825 The Verification service that receives the PASSporT, if it supports 826 this specification and chooses to, should interpret the "rcd" claim 827 as simply just an additional claim intended to deliver and/or 828 validate delivered Rich Call Data. 830 12.2. Example for applying "rcd" as claims only 832 In the case of [RFC8588] which is the PASSporT extension supporting 833 the SHAKEN specification [ATIS-1000074], a common case for an 834 Authentication service to co-exist in a CSP network along with the 835 authority over the calling name used for the call. Rather than 836 require two identity headers, the CSP Authentication Service can 837 apply both the SHAKEN PASSporT claims and extension and simply add 838 the "rcd" required claims defined in this document. 840 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 841 claims would be as follows: 843 Protected Header 844 { 845 "alg":"ES256", 846 "typ":"passport", 847 "ppt":"shaken", 848 "x5u":"https://cert.example.org/passport.cer" 849 } 850 Payload 851 { 852 "attest":"A", 853 "dest":{"tn":["12025551001"]}, 854 "iat":1443208345, 855 "orig":{"tn":"12025551000"}, 856 "origid":"123e4567-e89b-12d3-a456-426655440000", 857 "rcd":{"nam":"James Bond"} 858 } 860 A Verification Service that supports "rcd" and "shaken" PASSporT 861 extensions will be able to receive the above PASSporT and interpret 862 both the "shaken" claims as well as the "rcd" defined claim. 864 If the Verification Service only understands the "shaken" extension 865 claims but doesn't support "rcd", the "rcd" can simply be ignored and 866 disregarded. 868 13. Acknowledgements 870 We would like to thank David Hancock, Robert Sparks, Russ Housley, 871 and Eric Burger for helpful suggestions and comments. 873 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 891 Change Controller: IESG 893 Specification Document(s): [RFCThis] 895 Claim Name: "crn" 897 Claim Description: Call Reason 899 Change Controller: IESG 901 Specification Document(s): [RFCThis] 903 14.2. PASSporT Types 905 This specification requests that the IANA add a new entry to the 906 PASSporT Types registry for the type "rcd" which is specified in 907 [RFCThis]. 909 14.3. PASSporT RCD Types 911 This document requests that the IANA create a new registry for 912 PASSporT RCD types. Registration of new PASSporT RCD types shall be 913 under the Specification Required policy. 915 This registry is to be initially populated with three values, "nam", 916 "jcd", and "jcl", which are specified in [RFCThis]. 918 15. Security Considerations 920 Revealing information such as the name, location, and affiliation of 921 a person necessarily entails certain privacy risks. Baseline 922 PASSporT has no particular confidentiality requirement, as the 923 information it signs over in a using protocol like SIP is all 924 information that SIP carries in the clear anyway. Transport-level 925 security can hide those SIP fields from eavesdroppers, and the same 926 confidentiality mechanisms would protect any PASSporT(s) carried in 927 SIP. 929 16. References 931 16.1. Normative References 933 [I-D.ietf-sipcore-callinfo-rcd] 934 Wendt, C. and J. Peterson, "SIP Call-Info Parameters for 935 Rich Call Data", draft-ietf-sipcore-callinfo-rcd-00 (work 936 in progress), November 2020. 938 [I-D.ietf-stir-oob] 939 Rescorla, E. and J. Peterson, "STIR Out-of-Band 940 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 941 in progress), March 2020. 943 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 944 A., Peterson, J., Sparks, R., Handley, M., and E. 945 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 946 DOI 10.17487/RFC3261, June 2002, 947 . 949 [RFC4627] Crockford, D., "The application/json Media Type for 950 JavaScript Object Notation (JSON)", RFC 4627, 951 DOI 10.17487/RFC4627, July 2006, 952 . 954 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 955 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 956 DOI 10.17487/RFC6919, April 2013, 957 . 959 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 960 DOI 10.17487/RFC7095, January 2014, 961 . 963 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 964 Telephone Identity Problem Statement and Requirements", 965 RFC 7340, DOI 10.17487/RFC7340, September 2014, 966 . 968 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 969 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 970 . 972 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 973 "Authenticated Identity Management in the Session 974 Initiation Protocol (SIP)", RFC 8224, 975 DOI 10.17487/RFC8224, February 2018, 976 . 978 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 979 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 980 . 982 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 983 Credentials: Certificates", RFC 8226, 984 DOI 10.17487/RFC8226, February 2018, 985 . 987 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 988 (PaSSporT) Extension for Signature-based Handling of 989 Asserted information using toKENs (SHAKEN)", RFC 8588, 990 DOI 10.17487/RFC8588, May 2019, 991 . 993 16.2. Informative References 995 [ATIS-1000074] 996 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 997 of Asserted information using toKENs (SHAKEN) 998 ", January 2017. 1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1002 Requirement Levels", BCP 14, RFC 2119, 1003 DOI 10.17487/RFC2119, March 1997, 1004 . 1006 Authors' Addresses 1007 Jon Peterson 1008 Neustar Inc. 1009 1800 Sutter St Suite 570 1010 Concord, CA 94520 1011 US 1013 Email: jon.peterson@neustar.biz 1015 Chris Wendt 1016 Comcast 1017 Comcast Technology Center 1018 Philadelphia, PA 19103 1019 USA 1021 Email: chris-ietf@chriswendt.net