idnits 2.17.1 draft-ietf-stir-passport-rcd-05.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 direcly 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 URI 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 yet another addition 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 over 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 MUST be used. For re-construction of the "jcl", the Call-Info header with purpose "jcard" MUST be used. "jcd" claim MAY NOT be used as part of compact form. -- The document date (November 04, 2019) is 1632 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 826, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-05 ** Downref: Normative reference to an Informational draft: draft-ietf-stir-oob (ref. 'I-D.ietf-stir-oob') ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 4 errors (**), 0 flaws (~~), 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: May 7, 2020 Comcast 6 November 04, 2019 8 PASSporT Extension for Rich Call Data 9 draft-ietf-stir-passport-rcd-05 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 May 7, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 5 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.2. JWT Constraint for "rcdi" claim . . . . . . . . . . . . . 8 74 6. "rcd" Usage . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.1. Example "rcd" PASSporTs . . . . . . . . . . . . . . . . . 9 76 7. Compact form of "rcd" PASSporT . . . . . . . . . . . . . . . 11 77 7.1. Compact form of the "rcd" PASSporT claim . . . . . . . . 11 78 7.2. Compact form of the "rcdi" PASSporT claim . . . . . . . . 11 79 8. Further Information Associated with Callers . . . . . . . . . 11 80 9. Third-Party Uses . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Signing as a Third Party . . . . . . . . . . . . . . . . 13 82 10. Levels of Assurance . . . . . . . . . . . . . . . . . . . . . 14 83 11. Using "rcd" in SIP . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Authentication Service Behavior . . . . . . . . . . . . 14 85 11.2. Verification Service Behavior . . . . . . . . . . . . . 15 86 12. Using "rcd" as additional claims to other PASSporT extensions 16 87 12.1. Procedures for applying "rcd" as claims only . . . . . . 16 88 12.2. Example for applying "rcd" as claims only . . . . . . . 16 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 14.1. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17 92 14.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 18 93 14.3. PASSporT RCD Types . . . . . . . . . . . . . . . . . . . 18 94 15. Security Considerations . . . . . . . . . . . . . . . . . . . 18 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 16.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 16.2. Informative References . . . . . . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 100 1. Introduction 102 PASSporT [RFC8225] is a token format based on JWT [RFC7519] for 103 conveying cryptographically-signed information about the people 104 involved in personal communications; it is used to convey a signed 105 assertion of the identity of the participants in real-time 106 communications established via a protocol like SIP [RFC8224]. The 107 STIR problem statement [RFC7340] declared securing the display name 108 of callers outside of STIR's initial scope, so baseline STIR provides 109 no features for caller name. This specification documents an 110 optional mechanism for PASSporT and the associated STIR mechanisms 111 which extends PASSporT to carry additional elements conveying richer 112 information: information that is intended to be rendered to an end 113 user to assist a called party in determining whether to accept or 114 trust incoming communications. This includes the name of the person 115 on one side of a communications session, the traditional "Caller ID" 116 of the telephone network, along with related display information that 117 would be rendered to the called party during alerting, or potentially 118 used by an automaton to determine whether and how to alert a called 119 party. 121 Traditional telephone network signaling protocols have long supported 122 delivering a 'calling name' from the originating side, though in 123 practice, the terminating side is often left to derive a name from 124 the calling party number by consulting a local address book or an 125 external database. SIP similarly can carry a 'display-name' in the 126 From header field value from the originating to terminating side, 127 though it is an unsecured field that is not commonly trusted. The 128 same is true of information in the Call-Info header field. 130 The baseline use case for this document will be extending PASSporT to 131 provide cryptographic protection for the "display-name" field of SIP 132 requests as well as further "rich call data" (RCD) about the caller, 133 which includes the contents of the Call-Info header field or other 134 data structures that can be added to the PASSporT. This document 135 furthermore specifies a third-party profile that would allow external 136 authorities to convey rich information associated with a calling 137 number via a new type of PASSporT. Finally, this document describes 138 how to preserve the integrity of the RCD in scenarios where there may 139 be non-authoritative users that may be initiating and signing RCD and 140 therefore a constraint on the RCD data that a PASSporT can attest via 141 certificate-level controls. 143 2. Terminology 145 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 146 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 147 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 148 described in [RFC2119] and [RFC6919]. 150 3. Overview of the use of the Rich Call Data PASSporT extension 152 The main intended use of the signing of Rich Call Data (RCD) using 153 STIR [RFC8224] and as a PASSporT extension [RFC8225] is from an 154 entity that is associated with the originated with the call. Either 155 the caller themselves if they are authoritative, or a service 156 provider, or a third-party service may be authoritative over the rich 157 call data on behalf of the caller or service provider representing 158 the caller. 160 The RCD described in this document is of two main categories. The 161 first data is a more traditional set of info about a caller 162 associated with "display-name" in SIP [RFC3261] and typically is the 163 calling name that is a textual description of the caller. The second 164 data is a set of RCD that is defined as part of the jCard definitions 165 or extensions to that data. [I.D.wendt-sipcore-callinfo-rcd-00] 166 describes the use of jCard as RCD with the "jcard" Call-Info purpose 167 token. Either or both of these two types of data can be incorporated 168 into a "rcd" claim defined in this document. 170 In addition to the type of RCD that can be signed, there are three 171 normative modes of use of the signing of Rich Call Data (RCD). The 172 first and simplest mode is exclusively for when RCD content is 173 direcly included as part of the claims (i.e. no URIs are included in 174 the content). In this mode the set of claims is signed via standard 175 PASSporT [RFC8225] and SIP identity header [RFC8224] procedures. The 176 second mode is an extension of the first where a "rcd" claim is 177 included and the content MAY or MAY NOT include URI external 178 resources. In this mode, a "rcdi" integrity claim MUST be included. 179 This integrity claim is defined in this document and provides a 180 digest of the content so that, particularly for the case where there 181 is URI references in the RCD, the content of that RCD can be 182 comprehensively validated that it was received as intended by the 183 signer of the PASSporT. The third mode is yet another addition to 184 both the first and second modes and incorporates the ability to 185 include the digest of the integrity claim as a required value in the 186 certificate used to create the PASSporT digital signature. This mode 187 allows for cases where there is a different authoritative entity over 188 the content of the RCD, separate from the signer of the PASSporT 189 itself allowing the ability to have policy around the content and 190 potential review or pre-determination of allowed RCD content. 192 4. Overview of Rich Call Data integrity 194 When incorporating call data that represents a user, even in 195 traditional calling name services today, often there is policy and 196 restrictions around what data is allowed to be used. Whether 197 preventing offensive language or icons or enforcing uniqueness or 198 whatever potential policy either via regulatory rules, a customer 199 service agreements, or an enterprise brand consistency there may be 200 the desire to pre-certify the specific use of rich data. This 201 document defines a mechanism that allows for an indirect party that 202 controls the policy to approve or certify the content, create a 203 cryptographic digest that can be used to validate that data and 204 applies a constraint in the certificate to allow the recipient and 205 verifier to validate that the specific content of the RCD is as 206 intended at its creation and approval or certification. 208 The integrity mechanism is a process of generating a sufficiently 209 strong cryptographic digest for both the "rcd" claim contents (e.g. 210 "nam" and "jcd") defined below and the resources defined by one or 211 more globally unique HTTPS URLs referenced by the contents (e.g. an 212 image file referenced by "jcd"). This mechanism is inspired and 213 based on the W3C Subresource Integrity specification 214 (http://www.w3.org/TR/SRI/). This mechanism additionally defines the 215 ability to constrain the digest and RCD integrity mechanism to be 216 mandatory without modification using JWT Constraints defined in 217 [RFC8226]. 219 5. PASSporT Claims 221 5.1. PASSporT "rcd" Claim 223 This specification defines a new JSON Web Token claim for "rcd", Rich 224 Call Data, the value of which is a JSON object that can contain one 225 or more key value pairs. This document defines a default set of key 226 values. 228 5.1.1. "nam" key 230 The "nam" key value is a display name, associated with the originator 231 of personal communications, which may for example derive from the 232 display-name component of the From header field value of a SIP 233 request, or a similar field in other PASSporT using protocols. This 234 key MUST be included once and MUST be included as as part of the 235 "rcd" claim value JSON object. If there is no string associated with 236 a display name, the claim value SHOULD then be an empty string. 238 5.1.2. "jcd" key 240 The "jcd" key value is defined to contain a value of a jCard 241 [RFC7095] JSON object. This jCard object is intended to and may 242 derive from the Call-Info header field value defined in [I.D.wendt- 243 sipcore-callinfo-rcd] with a type of "jcard". As also defined in 244 [I.D.wendt-sipcore-callinfo-rcd], format of the jCard and properties 245 used should follow the normative usage and formating rules and 246 procedures. It is an extensible object where the calling party can 247 provide both the standard types of information defined in jCard or 248 can use the built in extensibility of the jCard specification to add 249 additional information. The "jcd" is optional. If included, this 250 key MUST only be included once in the "rcd" JSON object and SHOULD 251 NOT be included if there is a "jcl" key included. The "jcd" and 252 "jcl" keys should be mutually exclusive. 254 5.1.3. "jcl" key 256 The "jcl" key value is defined to contain a HTTPS URL that refers the 257 recipient to a jCard [RFC7095] JSON object hosted on a HTTPS enabled 258 web server. This link is intended to and may derive from the Call- 259 Info header field value defined in [I.D.wendt-sipcore-callinfo-rcd] 260 with a type of "jcard". As also defined in [I.D.wendt-sipcore- 261 callinfo-rcd], format of the jCard and properties used should follow 262 the normative usage and formating rules and procedures. The "jcl" 263 key is optional. If included, this key MUST only be included once in 264 the "rcd" JSON object and SHOULD NOT be included if there is a "jcd" 265 key included. The "jcd" and "jcl" keys should be mutually exclusive. 267 5.1.4. "rcdi" RCD integrity Claim 269 The "rcdi" claim is an optional claim that if the application 270 requires integrity applied to the content of the "rcd" claim SHOULD 271 be included with a corresponding "rcd" claim. The value of the 272 "rcdi" key pair should contain a string that is defined as follows. 274 The first part of the string should define the crypto algorithm used 275 to generate the digest. For RCD, implementations MUST support the 276 following hash algorithms, "SHA256", "SHA384", or "SHA512". The SHA- 277 256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic 278 hash functions defined by the NIST. Implementations MAY support 279 additional algorithms, but MUST NOT support known weak algorithms 280 such as MD5 or SHA-1. In the future, the list of algorithms may re- 281 evaluated based on security best practices. The algorithms MUST be 282 represented in the text by "sha256", "sha384", or "sha512". The 283 character following the algorithm string MUST be a minus character, 284 "-". The subsequent characters MUST be the base64 encoded digest of 285 a canonicalized and concatenated string based on the "rcd" claim and 286 the URLs contained in the claim. The details of the creation of this 287 string are defined in the next section. 289 Example: 290 "rcdi" : "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO" 292 5.1.5. Creation of the "rcd" digest 294 In order to facilitate proper verification of the digest and whether 295 the "rcd" content was modified, the input to the digest must be 296 completely deterministic at three points in the process. First, at 297 the certification point where the content is evaluated to conform to 298 the application policy and the JWT constraint is applied to the 299 certificate containing the digest. Second, when the call is signed 300 at the Authentication Service, there may be a local policy to verify 301 that the provided "rcd" claim corresponds to the digest. Third, when 302 the "rcd" data is verified at the Verification Service, it MUST 303 verify the digest by constructing the "rcd" input digest string. 305 The procedures for the creation of the "rcd" input digest string is 306 as follows. 308 1. Arrange the keys in the "rcd" claim value to be in lexicographic 309 order. 311 2. Serialize the resulting "rcd" claim value JSON object to remove 312 all white space and line breaks. The procedures of this 313 deterministic JSON serialization is defined in [RFC8225], 314 Section 9. 316 3. Identify, in order of where they appear in the serialized string, 317 all of the URLs referencing external resource files. 319 4. Construct the "rcd" input string by first inserting the 320 serialized "rcd" claim value. 322 5. If there is at least one URL identified, insert a semicolon 323 character in the "rcd" input string. 325 6. Follow the semicolon with the Base64 encoded contents of resource 326 file referenced by the first URL. 328 7. Repeat steps 5 and 6 for any additionally identified 329 corresponding URLs. 331 Once the input digest string has been created, use this string to 332 create the base64 encoded digest output that can be inserted into the 333 "rcdi" claim as discussed in the last section. 335 Example "rcd" claim with URL: 336 "rcd": { "nam" : "James Bond", 337 "jcl" : "https://example.org/james_bond.json" 338 } 340 Example "rcd" input digest string (with line breaks for readability): 341 {"nam":"James Bond","jcl":"https://example.org/james_bond.json"}; 342 ONG##*NCCCDJK123...KLJASlkJlkjsadlf2e3 344 Example "rcdi" claim: 345 "rcdi":"sha256-u5AZzq6A9RINQZngK7T62em8M" 347 5.2. JWT Constraint for "rcdi" claim 349 Once both the contents of the "rcd" claim is certified and the 350 construction of the "rcdi" claim is complete, the "rcdi" digest is 351 linked to the STIR certificate associated with the signature in the 352 PASSporT via JWT Constraints as defined in [RFC8226] Section 8. 354 The certificate JWT Constraint MUST include both of the following: 356 o a "mustInclude" for the "rcd" claim 358 o a "mustInclude" for the "rcdi" claim and a "permittedValues" equal 359 to the created "rcdi" claim value string. 361 6. "rcd" Usage 363 The "rcd" claim may appear in any PASSporT claims object as an 364 optional element. The creator of a PASSporT MAY however add a "ppt" 365 value of "rcd" to the header of a PASSporT as well, in which case the 366 PASSporT claims MUST contain a "rcd" claim, and any entities 367 verifying the PASSporT object will be required to understand the 368 "ppt" extension in order to process the PASSporT in question. A 369 PASSporT header with the "ppt" included will look as follows: 371 { "typ":"passport", 372 "ppt":"rcd", 373 "alg":"ES256", 374 "x5u":"https://www.example.com/cert.cer" } 376 The PASSporT claims object will then contain the "rcd" key with its 377 corresponding value. The value of "rcd" is an array of JSON objects, 378 of which one, the "nam" object, is mandatory. The key syntax of 379 "nam" follows the display-name ABNF given in [RFC3261]. 381 After the header and claims PASSporT objects have been constructed, 382 their signature is generated normally per the guidance in [RFC8225]. 384 6.1. Example "rcd" PASSporTs 386 An example of a "nam" only PASSporT claims obejct is shown next (with 387 line breaks for readability only). 389 { "orig":{"tn":"12025551000"}, 390 "dest":{"tn":"12025551001"}, 391 "iat":1443208345, 392 "rcd":{"nam":"James Bond"} } 394 An example of a "nam" only PASSporT claims object with an "rcdi" 395 claim is shown next (with line breaks for readability only). 397 { "orig":{"tn":"12025551000"}, 398 "dest":{"tn":"12025551001"}, 399 "iat":1443208345, 400 "rcd":{"nam":"James Bond"} 401 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" 402 } 404 An example of a PASSporT claims object that includes the "jcd" which 405 is optional, but will also include the mandatory "nam" object is 406 shown next (with line breaks for readability only). 408 { "orig":{"tn":"12025551000"}, 409 "dest":{"tn":"12155551001"}, 410 "iat":1443208345, 411 "rcd":{"nam":"James Bond","jcd":["vcard",[["version",{},"text","4.0"], 412 ["fn",{},"text", "James Bond"], 413 ["n",{},"text",["Bond","James","","","Mr."]], 414 ["adr",{"type":"work"},"text", 415 ["","","3100 Massachusetts Avenue NW","Washington","DC","20008","USA"] 416 ], 417 ["email",{},"text","007@mi6-hq.com"], 418 ["tel",{"type":["voice","text","cell"],"pref":"1"},"uri", 419 "tel:+1-202-555-1000"], 420 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"], 421 ["bday",{},"date","19241116"], 422 ["logo",{},"uri", 423 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg" 424 ]]]}} 426 In an example PASSporT where a jCard is linked via HTTPS URL and 427 "jcl" a jCard file served at a particular URL will be created. 429 An example jCard JSON file is shown as follows: 431 ["vcard", 432 [ 433 ["version", {}, "text", "4.0"], 434 ["fn", {}, "text", "James Bond"], 435 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 436 ["adr", {"type":"work"}, "text", 437 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 438 "USA"] 439 ], 440 ["email", {}, "text", "007@mi6-hq.com"], 441 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 442 "tel:+1-202-555-1000"], 443 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 444 ["bday", {}, "date", "19241116"] 445 ["logo", {}, "uri", 446 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 447 ] 448 ] 450 If that jCard is hosted at the example address of 451 "https://example.org/james_bond.json", the corresponding PASSporT 452 claims object would be as follows (with line breaks for readability 453 only): 455 { "orig":{"tn":"12025551000"}, 456 "dest":{"tn":"12155551001"}, 457 "iat":1443208345, 458 "rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} 459 } 461 If we were to add a "rcdi" integrity claim to the last example, the 462 corresponding PASSporT claims object would be as follows (with line 463 breaks for readability only): 465 { "orig":{"tn":"12025551000"}, 466 "dest":{"tn":"12155551001"}, 467 "iat":1443208345, 468 "rcd":{"nam":"James Bond","jcl":"https://example.org/james_bond.json"} 469 "rcdi":"sha256-H8BRh8j48O9oYatfu5AZzq6A9R6dQZngK7T62em8MUt1FLm52t+eX6xO" 470 } 472 7. Compact form of "rcd" PASSporT 474 7.1. Compact form of the "rcd" PASSporT claim 476 Compact form of an "rcd" PASSporT claim has some restrictions but 477 mainly follows standard PASSporT compact form procedures. For re- 478 construction of the "nam" claim the string for the display-name in 479 the From header MUST be used. For re-construction of the "jcl", the 480 Call-Info header with purpose "jcard" MUST be used. "jcd" claim MAY 481 NOT be used as part of compact form. 483 7.2. Compact form of the "rcdi" PASSporT claim 485 Compact form of an "rcdi" PASSPorT claim shall be re-constructed 486 following the same "rcdi" defined digest procedures in this document 487 of all of the content and referenced URI content once downloaded. 489 8. Further Information Associated with Callers 491 Beyond naming information and the information that can be contained 492 in a jCard [RFC7095] object, there may be additional human-readable 493 information about the calling party that should be rendered to the 494 end user in order to help the called party decide whether or not to 495 pick up the phone. This is not limited to information about the 496 caller, but includes information about the call itself, which may 497 derive from analytics that determine based on call patterns or 498 similar data if the call is likely to be one the called party wants 499 to receive. Such data could include: 501 o information related to the location of the caller, or 503 o any organizations or institutions that the caller is associated 504 with, or even categories of institutions (is this a government 505 agency, or a bank, or what have you), or 507 o hyperlinks to images, such as logos or pictures of faces, or to 508 similar external profile information, or 510 o information that will be processed by an application before 511 rendering it to a user, like social networking data that shows 512 that an unknown caller is a friend-of-a-friend, or reputation 513 scores derived from crowdsourcing, or confidence scores based on 514 broader analytics about the caller and callee. 516 All of these data elements would benefit from the secure attestations 517 provided by the STIR and PASSporT frameworks. A new IANA registry 518 has been defined to hold potential values of the "rcd" array; see 519 Section 14.3. Specific extensions to the "rcd" PASSporT claim are 520 left for future specification. 522 While in the traditional telephone network, the business relationship 523 between calling customers and their telephone service providers is 524 the ultimate root of information about a calling party's name, some 525 other forms of data like crowdsourced reputation scores might derive 526 from third parties. It is more likely that when those elements are 527 present, they will be in a third-party "rcd" PASSporT. 529 9. Third-Party Uses 531 While rich data about the call can be provided by an originating 532 authentication service, the terminating side or an intermediary in 533 the call path could also acquire rich call data by querying a third- 534 party service. Such a service effectively acts as a STIR 535 Authentication Service, generating its own PASSporT, and that 536 PASSporT could be attached to a SIP call by either the originating or 537 terminating side. This third-party PASSporT attests information 538 about the calling number, rather than the call or caller itself, and 539 as such its RCD MUST NOT be used when a call lacks a first-party 540 PASSporT that assures verification services that the calling party 541 number is not spoofed. It is intended to be used in cases when the 542 originating side does not supply a display-name for the caller, so 543 instead some entity in the call path invokes a third-party service to 544 provide rich caller data for a call. 546 In telephone operations today, a third-party information service is 547 commonly queried with the calling party's number in order to learn 548 the name of the calling party, and potentially other helpful 549 information could also be passed over that interface. The value of 550 using a PASSporT to convey this information from third parties lies 551 largely in the preservation of the original authority's signature 552 over the data, and the potential for the PASSporT to be conveyed from 553 intermediaries to endpoint devices. Effectively, these use cases 554 form a sub-case of out-of-band [I-D.ietf-stir-oob] use cases. The 555 manner in which third-party services are discovered is outside the 556 scope of this document. 558 An intermediary use case might look as follows: a SIP INVITE carries 559 a display name in its From header field value and an initial PASSporT 560 object without the "rcd" claim. When the a terminating verification 561 service implemented at a SIP proxy server receives this request, and 562 determines that the signature is valid, it might query a third-party 563 service that maps telephone numbers to calling party names. Upon 564 receiving the PASSport in a response from that third-party service, 565 the terminating side could add a new Identity header field to the 566 request for the "rcd" PASSporT object provided by the third-party 567 service. It would then forward the INVITE to the terminating user 568 agent. If the display name in the "rcd" PASSporT object matches the 569 display name in the INVITE, then the name would presumably be 570 rendered to the end user by the terminating user agent. 572 A very similar flow could be followed by an intermediary closer to 573 the origination of the call. Presumably such a service could be 574 implemented at an originating network in order to decouple the 575 systems that sign for calling party numbers from the systems that 576 provide rich data about calls. 578 In an alternative use case, the terminating user agent might query a 579 third-party service. In this case, no new Identity header field 580 would be generated, though the terminating user agent might receive a 581 PASSporT object in return from the third-party service, and use the 582 "rcd" field in the object as a calling name to render to users while 583 alerting. 585 9.1. Signing as a Third Party 587 When a third party issues a PASSporT with an "rcd" claim, the 588 PASSporT MUST contain the "rcd" "ppt" type in its header object. It 589 moreover MUST include an "iss" claim as defined in [RFC7519] to 590 indicate the source of this PASSporT; that field SHOULD be populated 591 with the subject of the credential used to sign the PASSporT. 593 A PASSporT with a "ppt" of "rcd" MAY be signed with credentials that 594 do not have authority over the identity that appears in the "orig" 595 element of the PASSporT claims. Relying parties in STIR have always 596 been left to make their own authorization decisions about whether or 597 not the trust the signers of PASSporTs, and in the third-party case, 598 where an entity has explicitly queried a service to acquire the 599 PASSporT object, it may be some external trust or business 600 relationship that induces the relying party to trust a PASSporT. 602 An example of a Third Party issued PASSporT claims object is as 603 follows. 605 { "orig":{"tn":"12025551000"}, 606 "dest":{"tn":"12025551001"}, 607 "iat":1443208345, 608 "iss":"Example, Inc.", 609 "rcd":{"nam":"James Bond"} } 611 10. Levels of Assurance 613 As "rcd" can be provided by either first or third parties, relying 614 parties could benefit from an additional claim that indicates the 615 relationship of the attesting party to the caller. Even in first 616 party cases, this admits of some complexity: the Communications 617 Service Provider (CSP) to which a number was assigned might in turn 618 delegate the number to a reseller, who would then sell the number to 619 an enterprise, in which case the CSP might have little insight into 620 the caller's name. In third party cases, a caller's name could 621 derive from any number of data sources, on a spectrum between public 622 data scraped from web searches to a direct business relationship to 623 the caller. As multiple PASSporTs can be associated with the same 624 call, potentially a verification service could receive attestations 625 of the caller name from multiple sources, which have different levels 626 of granularity or accuracy. 628 Therefore PASSporTs that carry "rcd" data SHOULD also carry an 629 indication of the relationship of the generator of the PASSporT to 630 the caller. [TBD claim - take from SHAKEN?] 632 11. Using "rcd" in SIP 634 This section specifies SIP-specific usage for the "rcd" claim in 635 PASSporT, and in the SIP Identity header field value. Other using 636 protocols of PASSporT may define their own usages for the "rcd" 637 claim. 639 11.1. Authentication Service Behavior 641 An authentication service creating a PASSporT containing a "rcd" 642 claim MAY include a "ppt" for "rcd" or not. Third-party 643 authentication services following the behavior in Section 9.1 MUST 644 include a "ppt" of "rcd". If "ppt" does contain a "rcd", then any 645 SIP authentication services MUST add a "ppt" parameter to the 646 Identity header containing that PASSporT with a value of "rcd". The 647 resulting Identity header might look as follows: 649 Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 650 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 651 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ 652 info=;alg=ES256;ppt="rcd" 654 This specification assumes that by default, a SIP authentication 655 service will derive the value of "rcd", specifically only for the 656 "nam" key value, from the display-name component of the From header 657 field value of the request, alternatively for some calls this may 658 come from the P-Asserted-ID header. It is however a matter of 659 authentication service policy to decide how it populates the value of 660 "rcd" and "nam" key, which MAY also derive from other fields in the 661 request, from customer profile data, or from access to external 662 services. If the authentication service generates a PASSporT object 663 containing "rcd" with a value that is not equivalent to the From 664 header field display-name value, it MUST use the full form of the 665 PASSporT object in SIP. 667 11.2. Verification Service Behavior 669 [RFC8224] Section 6.2 Step 5 requires that specifications defining 670 "ppt" values describe any additional verifier behavior. The behavior 671 specified for the "ppt" values of "rcd" is as follows. If the 672 PASSporT is in compact form, then the verification service SHOULD 673 extract the display-name from the From header field value, if any, 674 and use that as the value for the "rcd" key when it recomputes the 675 header and claims of the PASSporT object. If the signature validates 676 over the recomputed object, then the verification should be 677 considered successful. 679 However, if the PASSport is in full form with a "ppt" value of "rcd", 680 then the verification service MUST extract the value associated with 681 the "rcd" "nam" key in the object. If the signature validates, then 682 the verification service can use the value of the "rcd" "nam" key as 683 the display name of calling party, which would in turn be rendered to 684 alerted users or otherwise leveraged in accordance with local policy. 685 This will allow SIP networks that convey the display name through a 686 field other than the From header field to interoperate with this 687 specification. 689 The third-party "rcd" PASSporT cases presents some new challenges, as 690 an attacker could attempt to cut-and-paste such a third-party 691 PASSporT into a SIP request in an effort to get the terminating user 692 agent to render the display name or confidence values it contains to 693 a call that should have no such assurance. A third-party "rcd" 694 PASSporT provides no assurance that the calling party number has not 695 been spoofed: if it is carried in a SIP request, for example, then 696 some other PASSporT in another Identity header field value would have 697 to carry a PASSporT attesting that. A verification service MUST 698 determine that the calling party number shown in the "orig" of the 699 "rcd" PASSporT corresponds to the calling party number of the call it 700 has received, and that the "iat" field of the "rcd" PASSporT is 701 within the date interval that the verification service would 702 ordinarily accept for a PASSporT. 704 Verification services may alter their authorization policies for the 705 credentials accepted to sign PASSporTs when third parties generate 706 PASSporT objects, per Section 9.1. This may include accepting a 707 valid signature over a PASSporT even if it is signed with a 708 credential that does not attest authority over the identity in the 709 "orig" claim of the PASSporT, provided that the verification service 710 has some other reason to trust the signer. No further guidance on 711 verification service authorization policy is given here. 713 The behavior of a SIP UAS upon receiving an INVITE containing a 714 PASSporT object with a "rcd" claim will largely remain a matter of 715 implementation policy. In most cases, implementations would render 716 this calling party name information to the user while alerting. Any 717 user interface additions to express confidence in the veracity of 718 this information are outside the scope of this specification. 720 12. Using "rcd" as additional claims to other PASSporT extensions 722 Rich Call Data, including, for example, calling name information, is 723 often data that is additive data to the personal communications 724 information defined in the core PASSporT data required to support the 725 security properties defined in [RFC8225]. For cases where the entity 726 that is originating the personal communications and additionally is 727 supporting the authentication service and also is the authority of 728 the Rich Call Data, rather than creating multiple identity headers 729 with multiple PASSporT extensions or defining multiple combinations 730 and permutations of PASSporT extension definitions, the 731 authentication service can alternatively directly add the "rcd" 732 claims to the PASSporT it is creating, whether it is constructed with 733 a PASSporT extension or not. 735 12.1. Procedures for applying "rcd" as claims only 737 For a given PASSporT using some other extension than "rcd", the 738 Authentication Service MAY additionally include the "rcd" claim as 739 defined in this document. This would result in a set of claims that 740 correspond to the original intended extension with the addition of 741 the "rcd" claim. 743 The Verification service that receives the PASSporT, if it supports 744 this specification and chooses to, should interpret the "rcd" claim 745 as simply just an additional claim intended to deliver and/or 746 validate delivered Rich Call Data. 748 12.2. Example for applying "rcd" as claims only 750 In the case of [RFC8588] which is the PASSporT extension supporting 751 the SHAKEN specification [ATIS-1000074], a common case for an 752 Authentication service to co-exist in a CSP network along with the 753 authority over the calling name used for the call. Rather than 754 require two identity headers, the CSP Authentication Service can 755 apply both the SHAKEN PASSporT claims and extension and simply add 756 the "rcd" required claims defined in this document. 758 For example, the PASSporT claims for the "shaken" PASSporT with "rcd" 759 claims would be as follows: 761 Protected Header 762 { 763 "alg":"ES256", 764 "typ":"passport", 765 "ppt":"shaken", 766 "x5u":"https://cert.example.org/passport.cer" 767 } 768 Payload 769 { 770 "attest":"A", 771 "dest":{"tn":["12025551001"]}, 772 "iat":1443208345, 773 "orig":{"tn":"12025551000"}, 774 "origid":"123e4567-e89b-12d3-a456-426655440000", 775 "rcd":{"nam":"James Bond"} 776 } 778 A Verification Service that supports "rcd" and "shaken" PASSporT 779 extensions will be able to receive the above PASSporT and interpret 780 both the "shaken" claims as well as the "rcd" defined claim. 782 If the Verification Service only understands the "shaken" extension 783 claims but doesn't support "rcd", the "rcd" can simply be ignored and 784 disregarded. 786 13. Acknowledgements 788 We would like to thank Robert Sparks, Russ Housley, and Eric Burger 789 for helpful suggestions and comments. 791 14. IANA Considerations 793 14.1. JSON Web Token Claim 795 This specification requests that the IANA add two new claims to the 796 JSON Web Token Claims registry as defined in [RFC7519]. 798 Claim Name: "rcd" 800 Claim Description: Rich Call Data Information 802 Change Controller: IESG 803 Specification Document(s): [RFCThis] 805 Claim Name: "rcdi" 807 Claim Description: Rich Call Data Integrity Information 809 Change Controller: IESG 811 Specification Document(s): [RFCThis] 813 14.2. PASSporT Types 815 This specification requests that the IANA add a new entry to the 816 PASSporT Types registry for the type "rcd" which is specified in 817 [RFCThis]. 819 14.3. PASSporT RCD Types 821 This document requests that the IANA create a new registry for 822 PASSporT RCD types. Registration of new PASSporT RCD types shall be 823 under the Specification Required policy. 825 This registry is to be initially populated with three values, "nam", 826 "jcd", and "jcl", which are specified in [RFCThis]. 828 15. Security Considerations 830 Revealing information such as the name, location, and affiliation of 831 a person necessarily entails certain privacy risks. Baseline 832 PASSporT has no particular confidentiality requirement, as the 833 information it signs over in a using protocol like SIP is all 834 information that SIP carries in the clear anyway. Transport-level 835 security can hide those SIP fields from eavesdroppers, and the same 836 confidentiality mechanisms would protect any PASSporT(s) carried in 837 SIP. 839 More TBD. 841 16. References 843 16.1. Normative References 845 [I-D.ietf-stir-oob] 846 Rescorla, E. and J. Peterson, "STIR Out-of-Band 847 Architecture and Use Cases", draft-ietf-stir-oob-05 (work 848 in progress), July 2019. 850 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 851 A., Peterson, J., Sparks, R., Handley, M., and E. 852 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 853 DOI 10.17487/RFC3261, June 2002, 854 . 856 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 857 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 858 DOI 10.17487/RFC6919, April 2013, 859 . 861 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 862 DOI 10.17487/RFC7095, January 2014, 863 . 865 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 866 Telephone Identity Problem Statement and Requirements", 867 RFC 7340, DOI 10.17487/RFC7340, September 2014, 868 . 870 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 871 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 872 . 874 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 875 "Authenticated Identity Management in the Session 876 Initiation Protocol (SIP)", RFC 8224, 877 DOI 10.17487/RFC8224, February 2018, 878 . 880 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 881 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 882 . 884 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 885 Credentials: Certificates", RFC 8226, 886 DOI 10.17487/RFC8226, February 2018, 887 . 889 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 890 (PaSSporT) Extension for Signature-based Handling of 891 Asserted information using toKENs (SHAKEN)", RFC 8588, 892 DOI 10.17487/RFC8588, May 2019, 893 . 895 16.2. Informative References 897 [ATIS-1000074] 898 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 899 of Asserted information using toKENs (SHAKEN) 900 ", January 2017. 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, 905 DOI 10.17487/RFC2119, March 1997, 906 . 908 Authors' Addresses 910 Jon Peterson 911 Neustar Inc. 912 1800 Sutter St Suite 570 913 Concord, CA 94520 914 US 916 Email: jon.peterson@neustar.biz 918 Chris Wendt 919 Comcast 920 Comcast Technology Center 921 Philadelphia, PA 19103 922 USA 924 Email: chris-ietf@chriswendt.net