idnits 2.17.1 draft-ietf-stir-passport-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '... claims that MUST be minimally used ...' RFC 2119 keyword, line 173: '...the "typ" header MUST be the string "p...' RFC 2119 keyword, line 186: '...signatures ES256 MUST be implemented a...' RFC 2119 keyword, line 233: '... The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined...' RFC 2119 keyword, line 264: '...orig" and "dest" MUST have claims wher...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2016) is 2786 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) == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-12 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR C. Wendt 3 Internet-Draft Comcast 4 Intended status: Standards Track J. Peterson 5 Expires: March 13, 2017 Neustar Inc. 6 September 9, 2016 8 Persona Assertion Token 9 draft-ietf-stir-passport-07 11 Abstract 13 This document defines a canonical string object or 'token' including 14 a digital signature for verifying the author of the token, their 15 authority to author the token and the information asserted in the 16 token, minimally, the originating identity or 'persona' corresponding 17 specifically to the originator of 'personal communications', or 18 signalled communications between a set of parties with identities. 19 The PASSporT token is cryptographically signed to protect the 20 integrity of the identify the originator of a personal communications 21 session (e.g. the telephone number or URI) and verify the assertion 22 of the identity information at the destination. The cryptographic 23 signature is defined with the intention that it can confidently 24 verify the originating persona even when the signature is sent to the 25 destination party over an insecure channel. PASSporT is particularly 26 useful for many personal communications applications over IP networks 27 and other multi-hop interconnection scenarios where the originating 28 and destination parties may not have a direct trusted relationship. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 13, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. PASSporT Token Overview . . . . . . . . . . . . . . . . . . . 4 66 3. PASSporT Header . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 4 68 3.2. "alg" (Algorithm) Header Parameter . . . . . . . . . . . 4 69 3.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . . 5 70 3.4. Example PASSporT header . . . . . . . . . . . . . . . . . 5 71 4. PASSporT Payload . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. JWT defined claims . . . . . . . . . . . . . . . . . . . 5 73 4.1.1. "iat" - Issued At claim . . . . . . . . . . . . . . . 6 74 4.2. PASSporT specific claims . . . . . . . . . . . . . . . . 6 75 4.2.1. Originating and Destination Identity Claims . . . . . 6 76 4.2.1.1. "tn" - Telephone Number identity . . . . . . . . 7 77 4.2.1.2. "uri" - URI identity . . . . . . . . . . . . . . 7 78 4.2.1.3. Future identity forms . . . . . . . . . . . . . . 7 79 4.2.1.4. Examples . . . . . . . . . . . . . . . . . . . . 7 80 4.2.2. "mky" - Media Key claim . . . . . . . . . . . . . . . 8 81 5. PASSporT Signature . . . . . . . . . . . . . . . . . . . . . 9 82 6. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 9 83 6.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . 10 84 6.2. Extended PASSporT Claims . . . . . . . . . . . . . . . . 10 85 7. Deterministic JSON Serialization . . . . . . . . . . . . . . 11 86 7.1. Example PASSport deterministic JSON form . . . . . . . . 11 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 8.1. Avoidance of replay and cut and paste attacks . . . . . . 12 89 8.2. Solution Considerations . . . . . . . . . . . . . . . . . 13 90 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 13 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 9.1. Media Type Registration . . . . . . . . . . . . . . . . . 13 93 9.1.1. Media Type Registry Contents Additions Requested . . 13 94 9.2. JSON Web Token Claims Registration . . . . . . . . . . . 15 95 9.2.1. Registry Contents Additions Requested . . . . . . . . 15 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 99 11.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Appendix A. Example PASSporT JWS Serialization and Signature . . 17 101 A.1. X.509 Private Key Certificate for Example . . . . . . . . 19 102 A.2. X.509 Public Key Certificate for Example . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 In today's IP-enabled telecommunications world, there is a growing 108 concern about the ability to trust incoming invitations for 109 communications sessions, including video, voice and messaging. 110 [RFC7340] As an example, modern telephone networks provide the 111 ability to spoof the calling party telephone number for many 112 legitimate purposes including providing network features and services 113 on the behalf of a legitimate telephone number. However, as we have 114 seen, bad actors have taken advantage of this ability for 115 illegitimate and fraudulent purposes meant to trick telephone users 116 to believe they are someone they are not. This problem can be 117 extended to many emerging forms of personal communications. 119 This document defines a method for creating and validating a token 120 that cryptographically verifies an originating identity, or more 121 generally a URI or telephone number representing the originator of 122 personal communications. Through extensions defined in this 123 document, in Section 5.2, other information relevant to the personal 124 communications can also be added to the token. The goal of PASSporT 125 is to provide a common framework for signing originating identity 126 related information in an extensible way. Additionally, this 127 functionality is independent of any specific personal communications 128 signaling call logic, so that the assertion of originating identity 129 related information can be implemented in a flexible way and can be 130 used in applications including end-to-end applications that require 131 different signaling protocols or gateways between different 132 communications systems. It is anticipated that signaling protocol 133 specific guidance will be provided in other related documents and 134 specifications to specify how to use and transport PASSporT tokens, 135 however this is intentionally out of scope for this document. 137 [I-D.ietf-stir-rfc4474bis] provides details of the use of PASSporT 138 within the SIP [RFC3261] signaling protocol for the signing and 139 verification of telephone numbers. 141 2. PASSporT Token Overview 143 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 144 and related specifications define a standard token format that can be 145 used as a way of encapsulating claimed or asserted information with 146 an associated digital signature using X.509 based certificates. JWT 147 provides a set of claims in JSON format that can conveniently 148 accommodate asserted originating identity information and is easily 149 extensible for extension mechanisms defined below. Additionally, JWS 150 provides a path for updating methods and cryptographic algorithms 151 used for the associated digital signatures. 153 JWS defines the use of JSON data structures in a specified canonical 154 format for signing data corresponding to JOSE header, JWS Payload, 155 and JWS Signature. JWT defines a set of claims that are represented 156 by specified key value pairs which can be extended with custom keys 157 for specific applications. The next sections define the header and 158 claims that MUST be minimally used with JWT and JWS for PASSporT. 160 3. PASSporT Header 162 The JWS token header is a JOSE header [RFC7515] Section 4, that 163 defines the type and encryption algorithm used in the token. 165 PASSporT header should include, at a minimum, the following header 166 parameters defined the the next three subsections. 168 3.1. "typ" (Type) Header Parameter 170 The "typ" (Type) Header Parameter is defined in JWS Section 4.1.9. to 171 declare the media type of the complete JWS. 173 For PASSporT Token the "typ" header MUST be the string "passport". 174 This represents that the encoded token is a JWT of type passport. 176 3.2. "alg" (Algorithm) Header Parameter 178 The "alg" (Algorithm) Header Parameter is defined in JWS 179 Section 4.1.1. This definition includes the ability to specify the 180 use of a cryptographic algorithm for the signature part of the JWS. 181 It also refers to a list of defined "alg" values as part of a 182 registry established by JSON Web Algorithms (JWA) [RFC7518] and 183 defined in Section 3.1. 185 For the creation and verification of PASSporT tokens and their 186 digital signatures ES256 MUST be implemented as defined in JWA 187 Section 3.4 188 Note that JWA defines other algorithms that may be utilized or 189 updated in the future depending on cryptographic strength 190 requirements guided by current security best practice. 192 3.3. "x5u" (X.509 URL) Header Parameter 194 As defined in JWS Section 4.1.5., the "x5u" header parameter defines 195 a URI [RFC3986] referring to the resource for the X.509 public key 196 certificate or certificate chain [RFC5280] corresponding to the key 197 used to digitally sign the JWS. Generally, as defined in JWS section 198 4.1.5, this would correspond to an HTTPS or DNSSEC resource using 199 integrity protection. 201 3.4. Example PASSporT header 203 An example of the header, would be the following, including the 204 specified passport type, ES256 algorithm, and a URI referencing the 205 network location of the certificate needed to validate the PASSporT 206 signature. 208 { 209 "typ":"passport", 210 "alg":"ES256", 211 "x5u":"https://cert.example.org/passport.cer" 212 } 214 4. PASSporT Payload 216 The token claims consist of the information which needs to be 217 verified at the destination party. These claims follow the 218 definition of a JWT claim [RFC7519] Section 4 and be encoded as 219 defined by the JWS Payload [RFC7515] Section 3. 221 PASSporT defines the use of a standard JWT defined claim as well as 222 custom claims corresponding to the two parties associated with 223 personal communications, the originator and destination as detailed 224 below. 226 Any claim key values outside the US-ASCII range should be encoded 227 using percent encoding as described in section 2.1 of [RFC3986], case 228 normalized as described in 6.2.2.1 of [RFC3986]. 230 4.1. JWT defined claims 231 4.1.1. "iat" - Issued At claim 233 The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined 234 claim Issued At. As defined this should be set to the date and time 235 of the origination of the personal communications. The time value 236 should be of the format defined in [RFC7519] Section 2 NumericDate. 237 This is included for securing the token against replay and cut and 238 paste attacks, as explained further in the security considerations in 239 section 6. 241 4.2. PASSporT specific claims 243 4.2.1. Originating and Destination Identity Claims 245 PASSporT defines claims that convey the identity of the origination 246 and destination of personal communications. Origination in the 247 context of PASSporT and for a given application's use of PASSporT is 248 the point in the network that has the authority to assert the callers 249 identity. This authority is represented in PASSporT by the 250 certificate holder and is signed at the applications choice of 251 authoritative point(s) in the network, for example, at a device that 252 has authenticated with a user, or at a network entity with an 253 authenticated trust relationship with that device and its user. 254 Destination represents the intended destination of the personal 255 communications, i.e. the identity(s) being called by the caller, The 256 destination point(s) determined by the application must have the 257 capability to verify the PASSporT token and the digital signature. 258 The PASSporT associated certificate is used to validate the authority 259 of the originating signer, generally via a certificate chain to the 260 trust anchor for that application. 262 The origination and destination identities are represented by two 263 claims that are required for PASSporT, the "orig" and "dest" claims. 264 Both "orig" and "dest" MUST have claims where the key represents an 265 identity type and the value is the identity string, both defined in 266 subsequent subsections. Currently, these identities can be 267 represented as either telephone numbers or Uniform Resource 268 Indicators (URIs). 270 The "orig" JSON object MUST only have one key value pair representing 271 the asserted identity of any type (currently either "tn" or "uri") of 272 the originator of the personal communications signaling. 274 The "dest" JSON object MUST have at least have one key value pair, 275 but could have multiple identity types (i.e. "tn" and/or "uri") but 276 only one of each. If both "tn" and "uri" are included, the JSON 277 object should list the "tn" array first and the "uri" array second. 278 Within the "tn" and "uri" arrays, the identity strings should be put 279 in lexicographical order including the scheme-specific portion of the 280 URI characters. Additionally, in the case of "dest" only, the 281 identity type key value MUST be an array signaled by standard JSON 282 brackets, even when there is a single identity value in the identity 283 type key value. 285 4.2.1.1. "tn" - Telephone Number identity 287 If the originating or destination identity is a telephone number, the 288 key representing the identity MUST be "tn". 290 Telephone Number strings for "tn" MUST be canonicalized according to 291 the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 8.3. 293 4.2.1.2. "uri" - URI identity 295 If any of the originating or destination identities is of the form 296 URI, as defined in [RFC3986], the key representing the identity MUST 297 be "uri" URI form of the identity. 299 4.2.1.3. Future identity forms 301 We recognize that in the future there may be other standard 302 mechanisms for representing identities. The "orig" and "dest" claims 303 currently support "tn" and "uri" but could be extended in the future 304 to allow for other identity types with new IANA registered unique 305 types to represent these forms. 307 4.2.1.4. Examples 309 Single Originator, with telephone number identity +12155551212, to 310 Single Destination, with URI identity 'sip:alice@example.com', 311 example: 313 { 314 "dest":{"uri":["sip:alice@example.com"]}, 315 "iat":"1443208345", 316 "orig":{"tn":"12155551212"} 317 } 319 Single Originator, with telephone number identity +12155551212, to 320 Multiple Destination Identities, with telephone number identity 321 +12125551212 and two URI identities, sip:alice@example.com and 322 sip:bob@example.com, example: 324 { 325 "dest":{ 326 "tn":["12125551212"], 327 "uri":["sip:alice@example.com", 328 "sip:bob@example.net"] 329 }, 330 "iat":"1443208345", 331 "orig":{"tn":"12155551212"} 332 } 334 4.2.2. "mky" - Media Key claim 336 Some protocols that use PASSporT may also want to protect media 337 security keys delivered within their signaling in order to bind those 338 keys to the identities established in the signaling layers. The 339 "mky" is an optional PASSporT claim defining the assertion of media 340 key fingerprints carried in SDP [RFC4566] via the "a=fingerprint" 341 attribute [RFC4572] Section 5. This claim can support either a 342 single or multiple fingerprints appearing in a single SDP body 343 corresponding to one or more media streams offered. 345 The "mky" claim MUST be formated in a JSON form including the "alg" 346 and "dig" keys with the corresponding algorithm and hexadecimal 347 values. If there are more that one fingerprint values associated 348 with different media streams in SDP, the fingerprint values MUST be 349 constructed as a JSON array denoted by bracket characters. 351 For the "dig" key value, the hash value MUST be the hexadecimal value 352 without any colons. The "mky" array MUST order the JSON objects 353 containing both "alg" and "dig" key values in lexicographic order of 354 the "alg" string first followed by the corresponding lexicographic 355 order of the "dig" string values. Within each of those objects the 356 JSON keys MUST have "alg" first and "dig" second. 358 An example claim with "mky" claim is as follows: 360 For an SDP offer that includes the following fingerprint values, 362 a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E: 363 5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1 364 a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65: 365 2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2 367 the PASSporT Payload object would be: 369 { 370 "dest":{"uri":["sip:alice@example.com"]}, 371 "iat":"1443208345", 372 "mky":[ 373 { 374 "alg":"sha-256", 375 "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54 376 F17A03A27DF9B07F4619B2" 377 }, 378 { 379 "alg":"sha-256", 380 "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C 381 AB3E4B652E7D463F5442CD54F1" 382 } 383 ], 384 "orig":{"tn":"12155551212"} 385 } 387 5. PASSporT Signature 389 The signature of the PASSporT is created as specified by JWS 390 [RFC7515] Section 5.1 Steps 1 through 6. PASSporT MUST use the JWS 391 Protected Header. For the JWS Payload and the JWS Protected Header, 392 the lexicographic ordering and white space rules described above, and 393 JSON serialization rules in Section 6 of this document MUST be 394 followed. 396 Appendix A of this document has a detailed example of how to follow 397 the steps to create the JWS Signature. 399 JWS [RFC7515] Section 5.1 Step 7 JWS JSON serialization is not 400 supported for PASSporT. 402 JWS [RFC7515] Section 5.1 Step 8 describes the method to create the 403 final JWS Compact Serialization form of the PASSporT Token. 405 6. Extending PASSporT 407 PASSporT includes the bare minimum set of claims needed to securely 408 assert the originating identity and support the secure properties 409 discussed in various parts of this document. JWT supports a straight 410 forward way to add additional claims by simply adding new claim key 411 pairs. PASSporT can be extended beyond the defined base set of 412 claims to represent other information requiring assertion or 413 validation beyond the originating identity itself as needed. 415 6.1. "ppt" (PASSporT) header parameter 417 For extension of the base set of claims defined in this document, a 418 new JWS header parameter "ppt" MUST be used with a unique string. 419 Any PASSporT extension should be defined in a specification 420 describing the PASSporT extension and the string used in the "ppt" 421 header string that defines any new claims that would extend the base 422 set of claims of PASSporT. 424 An example header with a PASSporT extension type of "foo" is as 425 follows: 427 { 428 "alg":"ES256", 429 "ppt":"foo", 430 "typ":"passport", 431 "x5u":"https://tel.example.org/passport.cer" 432 } 434 6.2. Extended PASSporT Claims 436 Specifications that define extensions to the PASSporT mechanism MUST 437 explicitly specify what claims they include beyond the base set of 438 claims from this document, the order in which they will appear, and 439 any further information necessary to implement the extension. All 440 extensions MUST include the baseline JWT elements specified in 441 Section 3; claims may only be appended to the claims object 442 specified; they can never be removed or re-ordered. Specifying new 443 claims follows the baseline JWT procedures ([RFC7519] Section 10.1). 444 Understanding an extension or new claims defined by the extension on 445 the destination verification of the PASSporT token is optional. The 446 creator of a PASSporT object cannot assume that destination systems 447 will understand any given extension. Verification of PASSporT tokens 448 by destination systems that do support an extension may then trigger 449 appropriate application-level behavior in the presence of an 450 extension; authors of extensions should provide appropriate 451 extension-specific guidance to application developers on this point. 453 An example set of extended claims, extending the first example in 454 Section 4.1.2.4. using "bar" as the newly defined claim would be as 455 follows: 457 { 458 "bar":"beyond all recognition" 459 "dest":{"uri":["sip:alice@example.com"]}, 460 "iat":"1443208345", 461 "orig":{"tn":"12155551212"} 462 } 464 7. Deterministic JSON Serialization 466 JSON, as a canonical format, can include spaces, line breaks and key 467 value pairs can occur in any order and therefore makes it, from a 468 string format, non-deterministic. In order to make the digital 469 signature verification work deterministically, the JSON 470 representation of the PASSporT Header and Claims, particularly if 471 PASSporT is used across multiple signaling environments, specifically 472 the JWS Protected Header object and JWS Payload object MUST be 473 computed as follows. 475 The JSON object MUST follow the rules for the construction of the 476 thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3 477 Step 1 only. Step 2 MUST NOT be performed; as noted in JWK this is 478 still a legal JWK object. 480 The PASSporT header and claim direct members MUST follow the 481 lexicographical ordering rules. Any top level JSON members that 482 contain JSON objects or arrays, such as "dest" or "mky" MUST follow 483 their own lexicographical ordering and whitespace and line break 484 rules for the sub-elements. This includes any header or claims 485 defined in future specifications using PASSporT. 487 7.1. Example PASSport deterministic JSON form 489 This section demonstrate the deterministic JSON serialization for the 490 example PASSporT Payload shown in Section 4.2.2. 492 The initial JSON object is shown here: 494 { 495 "dest":{"uri":["sip:alice@example.com"]}, 496 "orig":{"tn":"12155551212"} 497 "iat":"1443208345", 498 "mky":[ 499 { 500 "alg":"sha-256", 501 "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54 502 F17A03A27DF9B07F4619B2" 503 }, 504 { 505 "alg":"sha-256", 506 "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C 507 AB3E4B652E7D463F5442CD54F1" 508 } 509 ], 510 } 512 The parent members of the JSON object are as follows: 514 o "dest" 516 o "orig" 518 o "iat" 520 o "mky" 522 Their lexicographic order is: 524 o "dest" 526 o "iat" 528 o "mky" 530 o "orig" 532 The final constructed deterministic JSON serialization 533 representation, with whitespace and line breaks removed, (with line 534 breaks used for display purposes only) is: 536 {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky": 537 [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442 538 CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F 539 82183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], 540 "orig":{"tn":"12155551212"}} 542 8. Security Considerations 544 8.1. Avoidance of replay and cut and paste attacks 546 There are a number of security considerations for use of the token 547 for avoidance of replay and cut and paste attacks. PASSporT tokens 548 should be sent with other application level protocol information 549 (e.g. for SIP an INVITE as defined in [RFC3261]). In order to make 550 the token signature unique to a specific origination of personal 551 communications there should be a link between various information 552 provided in the token and information provided by the application 553 level protocol information. This uniqueness specified using the 554 following two claims: 556 o 'iat' claim should correspond to a date/time the message was 557 originated. It should also be within a relative time that is 558 reasonable for clock drift and transmission time characteristics 559 associated with the application using the PASSporT token. 561 Therefore, validation of the token should consider date and time 562 correlation, which could be influenced by signaling protocol 563 specific use and network time differences. 565 o 'dest' claim is included to prevent the valid re-use of a 566 previously originated message to send to another destination 567 party. 569 8.2. Solution Considerations 571 The use of PASSporT tokens based on the validation of the digital 572 signature and the associated certificate requires consideration of 573 the authentication and authority or reputation of the signer to 574 attest to the identity being asserted. It should be recognized that 575 the use of this token should not, in it's own right, be considered a 576 full solution for absolute non-repudiation of the identity being 577 asserted. It can and often is the case that the end user that the 578 identity represents and signer are not one in the same. However, 579 applications that use PASSporT should ensure the signer is in an 580 authoritative position to represent the user and authenticate the 581 user onto the communications network and should be the responsible 582 party for protecting the destination party from potential identity 583 spoofing in addition to other abuse of the communications network 584 outside of PASSporT. 586 8.3. Privacy Considerations 588 Because PASSporT explicitly includes claims of identifiers of parties 589 involved in communications, date and times, and potentially other 590 call detail, care should be taken outside of traditional protected or 591 private telephony communications paths where there may be concerns 592 about exposing information to either unintended or illegitimate 593 actors. These identifiers are often exposed through many 594 communications signaling protocols as of today, but appropriate 595 precautions should be taken. 597 9. IANA Considerations 599 9.1. Media Type Registration 601 9.1.1. Media Type Registry Contents Additions Requested 603 This section registers the "application/passport" media type 604 [RFC2046] in the "Media Types" registry in the manner described in 605 [RFC6838], which can be used to indicate that the content is a 606 PASSporT defined JWT and JWS. 608 o Type name: application 609 o Subtype name: passport 611 o Required parameters: n/a 613 o Optional parameters: n/a 615 o Encoding considerations: 8bit; application/passport values outside 616 the US-ASCII range are encoded using percent encoding as described 617 in section 2.1 of RFC 3986 (some values may be the empty string), 618 each separated from the next by a single period ('.') character. 620 o Security considerations: See the Security Considerations section 621 of RFC 7515. 623 o Interoperability considerations: n/a 625 o Published specification: draft-ietf-stir-passport-05 627 o Applications that use this media type: STIR and other applications 628 that require identity related assertion 630 o Fragment identifier considerations: n/a 632 o Additional information: 634 * Magic number(s): n/a 636 * File extension(s): n/a 638 * Macintosh file type code(s): n/a 640 o Person and email address to contact for further information: Chris 641 Wendt, chris-ietf@chriswendt.net 643 o Intended usage: COMMON 645 o Restrictions on usage: none 647 o Author: Chris Wendt, chris-ietf@chriswendt.net 649 o Change Controller: IESG 651 o Provisional registration? No 653 9.2. JSON Web Token Claims Registration 655 9.2.1. Registry Contents Additions Requested 657 o Claim Name: "orig" 659 o Claim Description: Originating Identity String 661 o Change Controller: IESG 663 o Specification Document(s): Section 3.2 of draft-ietf-stir- 664 passport-05 666 o Claim Name: "dest" 668 o Claim Description: Destination Identity String 670 o Change Controller: IESG 672 o Specification Document(s): Section 3.2 of draft-ietf-stir- 673 passport-05 675 o Claim Name: "mky" 677 o Claim Description: Media Key Fingerprint String 679 o Change Controller: IESG 681 o Specification Document(s): Section 3.2 of draft-ietf-stir- 682 passport-05 684 10. Acknowledgements 686 Particular thanks to members of the ATIS and SIP Forum NNI Task Group 687 including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill, 688 Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for 689 their review, ideas, and contributions also thanks to Henning 690 Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark 691 Miller, Ted Hardie, Dave Crocker, Robert Sparks for valuable feedback 692 on the technical and security aspects of the document. Additional 693 thanks to Harsha Bellur for assistance in coding the example tokens. 695 11. References 696 11.1. Normative References 698 [I-D.ietf-stir-rfc4474bis] 699 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 700 "Authenticated Identity Management in the Session 701 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-12 702 (work in progress), August 2016. 704 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 705 Extensions (MIME) Part Two: Media Types", RFC 2046, 706 DOI 10.17487/RFC2046, November 1996, 707 . 709 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 710 Resource Identifier (URI): Generic Syntax", STD 66, 711 RFC 3986, DOI 10.17487/RFC3986, January 2005, 712 . 714 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 715 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 716 July 2006, . 718 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 719 Transport Layer Security (TLS) Protocol in the Session 720 Description Protocol (SDP)", RFC 4572, 721 DOI 10.17487/RFC4572, July 2006, 722 . 724 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 725 Specifications and Registration Procedures", BCP 13, 726 RFC 6838, DOI 10.17487/RFC6838, January 2013, 727 . 729 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 730 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 731 2015, . 733 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 734 DOI 10.17487/RFC7518, May 2015, 735 . 737 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 738 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 739 . 741 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 742 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 743 2015, . 745 11.2. Informative References 747 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 748 A., Peterson, J., Sparks, R., Handley, M., and E. 749 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 750 DOI 10.17487/RFC3261, June 2002, 751 . 753 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 754 Housley, R., and W. Polk, "Internet X.509 Public Key 755 Infrastructure Certificate and Certificate Revocation List 756 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 757 . 759 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 760 Telephone Identity Problem Statement and Requirements", 761 RFC 7340, DOI 10.17487/RFC7340, September 2014, 762 . 764 Appendix A. Example PASSporT JWS Serialization and Signature 766 For PASSporT, there will always be a JWS with the following members: 768 o "protected", with the value BASE64URL(UTF8(JWS Protected Header)) 770 o "payload", with the value BASE64URL (JWS Payload) 772 o "signature", with the value BASE64URL(JWS Signature) 774 This example will follow the steps in JWS [RFC7515] Section 5.1, 775 steps 1-6 and 8 and incorporates the additional serialization steps 776 required for PASSporT. 778 Step 1 for JWS references the JWS Payload, an example PASSporT 779 Payload is as follows: 781 { 782 "dest":{"uri":["sip:alice@example.com"]} 783 "iat":"1443208345", 784 "orig":{"tn":"12155551212"} 785 } 787 This would be serialized to the form (with line break used for 788 display purposes only): 790 {"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345", 791 "orig":{"tn":"12155551212"}} 793 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 794 line break used for display purposes only): 796 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd 797 CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 799 For Step 3, an example PASSporT Protected Header comprising the JOSE 800 Header is as follows: 802 { 803 "typ":"passport", 804 "alg":"ES256", 805 "x5u":"https://cert.example.org/passport.cer" 806 } 808 This would be serialized to the form (with line break used for 809 display purposes only): 811 {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ 812 passport.cer"} 814 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 815 and encoding produces this value (with line break used for display 816 purposes only): 818 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 819 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 821 Step 5 and Step 6 performs the computation of the digital signature 822 of the PASSporT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 823 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 824 algorithm and the BASE64URL(JWS Signature). 826 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso 827 jNCpTzO3QfPOlckGaS6hEck7w 829 Step 8 describes how to create the final PASSporT token, 830 concatenating the values in the order Header.Payload.Signature with 831 period ('.') characters. For the above example values this would 832 produce the following (with line breaks between period used for 833 readability purposes only): 835 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly 836 9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 837 . 838 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd 839 CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 840 . 841 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso 842 jNCpTzO3QfPOlckGaS6hEck7w 844 A.1. X.509 Private Key Certificate for Example 846 -----BEGIN EC PRIVATE KEY----- 847 MHcCAQEEIFeZ1R208QCvcu5GuYyMfG4W7sH4m99/7eHSDLpdYllFoAoGCCqGSM49 848 AwEHoUQDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH78YTU8qLS8I5HLHSSmlATLcs 849 lQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 850 -----END EC PRIVATE KEY----- 852 A.2. X.509 Public Key Certificate for Example 854 -----BEGIN PUBLIC KEY----- 855 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 856 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 857 -----END PUBLIC KEY----- 859 Authors' Addresses 861 Chris Wendt 862 Comcast 863 One Comcast Center 864 Philadelphia, PA 19103 865 USA 867 Email: chris-ietf@chriswendt.net 869 Jon Peterson 870 Neustar Inc. 871 1800 Sutter St Suite 570 872 Concord, CA 94520 873 US 875 Email: jon.peterson@neustar.biz