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