idnits 2.17.1 draft-ietf-stir-passport-08.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 157: '... claims that MUST be minimally used ...' RFC 2119 keyword, line 172: '...the "typ" header MUST be the string "p...' RFC 2119 keyword, line 185: '... implementations MUST support ES256 as...' RFC 2119 keyword, line 186: '... JWA [RFC7518] Section 3.4. Implementations MAY support other...' RFC 2119 keyword, line 236: '... The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined...' (29 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 26, 2016) is 2766 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 745, but not defined == 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 (~~), 4 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 30, 2017 Neustar Inc. 6 September 26, 2016 8 Personal Assertion Token (PASSporT) 9 draft-ietf-stir-passport-08 11 Abstract 13 This document defines a method for creating and validating a token 14 that cryptographically verifies an originating identity, or more 15 generally a URI or telephone number representing the originator of 16 personal communications. The PASSporT token is cryptographically 17 signed to protect the integrity of the identity the originator and to 18 verify the assertion of the identity information at the destination. 19 The cryptographic signature is defined with the intention that it can 20 confidently verify the originating persona even when the signature is 21 sent to the destination party over an insecure channel. PASSporT is 22 particularly useful for many personal communications applications 23 over IP networks and other multi-hop interconnection scenarios where 24 the originating and destination parties may not have a direct trusted 25 relationship. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 30, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. PASSporT Token Overview . . . . . . . . . . . . . . . . . . . 3 63 3. PASSporT Header . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 4 65 3.2. "alg" (Algorithm) Header Parameter . . . . . . . . . . . 4 66 3.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . . 5 67 3.4. Example PASSporT header . . . . . . . . . . . . . . . . . 5 68 4. PASSporT Payload . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. JWT defined claims . . . . . . . . . . . . . . . . . . . 5 70 4.1.1. "iat" - Issued At claim . . . . . . . . . . . . . . . 5 71 4.2. PASSporT specific claims . . . . . . . . . . . . . . . . 6 72 4.2.1. Originating and Destination Identity Claims . . . . . 6 73 4.2.2. "mky" - Media Key claim . . . . . . . . . . . . . . . 8 74 5. PASSporT Signature . . . . . . . . . . . . . . . . . . . . . 9 75 6. Compact form of PASSporT . . . . . . . . . . . . . . . . . . 9 76 6.1. Example Compact form PASSporT Token . . . . . . . . . . . 10 77 7. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 10 78 7.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . 11 79 7.2. Example extended PASSporT header . . . . . . . . . . . . 11 80 7.3. Extended PASSporT Claims . . . . . . . . . . . . . . . . 11 81 8. Deterministic JSON Serialization . . . . . . . . . . . . . . 12 82 8.1. Example PASSport deterministic JSON form . . . . . . . . 12 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 9.1. Avoidance of replay and cut and paste attacks . . . . . . 14 85 9.2. Solution Considerations . . . . . . . . . . . . . . . . . 14 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 10.1. Media Type Registration . . . . . . . . . . . . . . . . 15 88 10.1.1. Media Type Registry Contents Additions Requested . . 15 89 10.2. JSON Web Token Claims Registration . . . . . . . . . . . 16 90 10.2.1. Registry Contents Additions Requested . . . . . . . 16 91 10.3. JSON Web Signature and Encryption Header Parameter 92 Registry . . . . . . . . . . . . . . . . . . . . . . . . 16 93 10.3.1. Registry Contents Additions Requested . . . . . . . 16 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 97 12.2. Informative References . . . . . . . . . . . . . . . . . 18 98 Appendix A. Example ES256 based PASSporT JWS Serialization and 99 Signature . . . . . . . . . . . . . . . . . . . . . 18 100 A.1. X.509 Private Key for ES256 Example** . . . . . . . . . . 20 101 A.2. X.509 Public Key for ES256 Example** . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 In today's IP-enabled telecommunications world, there is a growing 107 concern about the ability to trust incoming invitations for 108 communications sessions, including video, voice and messaging 109 [RFC7340]. As an example, modern telephone networks provide the 110 ability to spoof the calling party telephone number for many 111 legitimate purposes including providing network features and services 112 on the behalf of a legitimate telephone number. However, as we have 113 seen, bad actors have taken advantage of this ability for 114 illegitimate and fraudulent purposes meant to trick telephone users 115 to believe they are someone they are not. This problem can be 116 extended to many emerging forms of personal communications. 118 This document defines a method for creating and validating a token 119 that cryptographically verifies an originating identity, or more 120 generally a URI or telephone number representing the originator of 121 personal communications. Through extensions defined in this 122 document, in Section 7, other information relevant to the personal 123 communications can also be added to the token. The goal of PASSporT 124 is to provide a common framework for signing originating identity 125 related information in an extensible way. Additionally, this 126 functionality is independent of any specific personal communications 127 signaling call logic, so that the assertion of originating identity 128 related information can be implemented in a flexible way and can be 129 used in applications including end-to-end applications that require 130 different signaling protocols or gateways between different 131 communications systems. It is anticipated that signaling protocol 132 specific guidance will be provided in other related documents and 133 specifications to specify how to use and transport PASSporT tokens, 134 however this is intentionally out of scope for this document. 136 [I-D.ietf-stir-rfc4474bis] provides details of the use of PASSporT 137 within SIP [RFC3261] signaling protocol for the signing and 138 verification of telephone numbers and SIP URIs. 140 2. PASSporT Token Overview 142 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 143 and related specifications define a standard token format that can be 144 used as a way of encapsulating claimed or asserted information with 145 an associated digital signature using X.509 based certificates. JWT 146 provides a set of claims in JSON format that can conveniently 147 accommodate asserted originating identity information and is easily 148 extensible for extension mechanisms defined below. Additionally, JWS 149 provides a path for updating methods and cryptographic algorithms 150 used for the associated digital signatures. 152 JWS defines the use of JSON data structures in a specified canonical 153 format for signing data corresponding to JOSE header, JWS Payload, 154 and JWS Signature. JWT defines a set of claims that are represented 155 by specified key value pairs which can be extended with custom keys 156 for specific applications. The next sections define the header and 157 claims that MUST be minimally used with JWT and JWS for PASSporT. 159 3. PASSporT Header 161 The JWS token header is a JOSE header, [RFC7515] Section 4, that 162 defines the type and encryption algorithm used in the token. 164 PASSporT header should include, at a minimum, the header parameters 165 defined in the next three subsections. 167 3.1. "typ" (Type) Header Parameter 169 The "typ" (Type) Header Parameter is defined in JWS [RFC7515] 170 Section 4.1.9. to declare the media type of the complete JWS. 172 For PASSporT Token the "typ" header MUST be the string "passport". 173 This represents that the encoded token is a JWT of type passport. 175 3.2. "alg" (Algorithm) Header Parameter 177 The "alg" (Algorithm) Header Parameter is defined in JWS [RFC7515] 178 Section 4.1.1. This definition includes the ability to specify the 179 use of a cryptographic algorithm for the signature part of the JWS. 180 It also refers to a list of defined "alg" values as part of a 181 registry established by JSON Web Algorithms (JWA) [RFC7518] 182 Section 3.1. 184 For the creation and verification of PASSporT tokens and their 185 digital signatures, implementations MUST support ES256 as defined in 186 JWA [RFC7518] Section 3.4. Implementations MAY support other 187 algorithms registered in the JSON Web Signature and Encryption 188 Algorithms registry created by [RFC7518]. The contents of that 189 registry may be updated in the future depending on cryptographic 190 strength requirements guided by current security best practice. The 191 mandatory-to-support algorithm for PASSporT tokens may likewise be 192 updated in future updates to this document. 194 3.3. "x5u" (X.509 URL) Header Parameter 196 As defined in JWS [RFC7515] Section 4.1.5., the "x5u" header 197 parameter defines a URI [RFC3986] referring to the resource for the 198 X.509 public key certificate or certificate chain [RFC5280] 199 corresponding to the key used to digitally sign the JWS. Generally, 200 as defined in JWS [RFC7515] section 4.1.5, this would correspond to 201 an HTTPS or DNSSEC resource using integrity protection. 203 3.4. Example PASSporT header 205 An example of the header, would be the following, including the 206 specified passport type, ES256 algorithm, and a URI referencing the 207 network location of the certificate needed to validate the PASSporT 208 signature. 210 { 211 "typ":"passport", 212 "alg":"ES256", 213 "x5u":"https://cert.example.org/passport.cer" 214 } 216 4. PASSporT Payload 218 The token claims consist of the information which needs to be 219 verified at the destination party. These claims follow the 220 definition of a JWT claim [RFC7519] Section 4 and are encoded as 221 defined by the JWS Payload [RFC7515] Section 3. 223 PASSporT defines the use of a standard JWT defined claim as well as 224 custom claims corresponding to the two parties associated with 225 personal communications, the originator and destination as detailed 226 below. 228 Any claim key values outside the US-ASCII range should be encoded 229 using percent encoding as described in Section 2.1 of [RFC3986], case 230 normalized as described in 6.2.2.1 of [RFC3986]. 232 4.1. JWT defined claims 234 4.1.1. "iat" - Issued At claim 236 The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined 237 claim Issued At. As defined the "iat" should be set to the date and 238 time of issuance of the JWT and MUST the origination of the personal 239 communications. The time value should be of the format defined in 240 [RFC7519] Section 2 NumericDate. This is included for securing the 241 token against replay and cut and paste attacks, as explained further 242 in the security considerations in Section 9. 244 4.2. PASSporT specific claims 246 4.2.1. Originating and Destination Identity Claims 248 PASSporT defines claims that convey the identity of the origination 249 and destination of personal communications. Origination in the 250 context of PASSporT and for a given application's use of PASSporT is 251 the point in the network that has the authority to assert the callers 252 identity. This authority is represented in PASSporT by the 253 certificate holder and is signed at the applications choice of 254 authoritative point(s) in the network, for example, at a device that 255 has authenticated with a user, or at a network entity with an 256 authenticated trust relationship with that device and it's user. 257 Destination represents the intended destination of the personal 258 communications, i.e. the identity(s) being called by the caller. The 259 destination point(s) determined by the application need to have the 260 capability to verify the PASSporT token and the digital signature. 261 The PASSporT associated certificate is used to validate the authority 262 of the originating signer, generally via a certificate chain to the 263 trust anchor for that application. 265 The origination and destination identities are represented by two 266 claims that are required for PASSporT, the "orig" and "dest" claims. 267 Both "orig" and "dest" MUST have claims where the key represents an 268 identity type and the value is the identity string, both defined in 269 subsequent subsections. Currently, these identities can be 270 represented as either telephone numbers or Uniform Resource 271 Indicators (URIs). 273 The "orig" JSON object MUST only have one key value pair representing 274 the asserted identity of any type (currently either "tn" or "uri") of 275 the originator of the personal communications signaling. 277 The "dest" JSON object MUST have at least have one key value pair, 278 but could have multiple identity types (i.e. "tn" and/or "uri") but 279 only one of each. If both "tn" and "uri" are included, the JSON 280 object should list the "tn" array first and the "uri" array second. 281 Within the "tn" and "uri" arrays, the identity strings should be put 282 in lexicographical order including the scheme-specific portion of the 283 URI characters. Additionally, in the case of "dest" only, the 284 identity type key value MUST be an array signaled by standard JSON 285 brackets, even when there is a single identity value in the identity 286 type key value. 288 4.2.1.1. "tn" - Telephone Number identity 290 If the originating or destination identity is a telephone number, the 291 key representing the identity MUST be "tn". 293 Telephone Number strings for "tn" MUST be canonicalized according to 294 the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 8.3. 296 4.2.1.2. "uri" - URI identity 298 If any of the originating or destination identities is of the form 299 URI, as defined in [RFC3986], the key representing the identity MUST 300 be "uri" URI form of the identity. 302 4.2.1.3. Future identity forms 304 We recognize that in the future there may be other standard 305 mechanisms for representing identities. The "orig" and "dest" claims 306 currently support "tn" and "uri" but could be extended in the future 307 to allow for other identity types with new IANA registered unique 308 types to represent these forms. 310 4.2.1.4. Examples 312 Single Originator, with telephone number identity +12155551212, to 313 Single Destination, with URI identity 'sip:alice@example.com', 314 example: 316 { 317 "dest":{"uri":["sip:alice@example.com"]}, 318 "iat":"1443208345", 319 "orig":{"tn":"12155551212"} 320 } 322 Single Originator, with telephone number identity +12155551212, to 323 Multiple Destination Identities, with telephone number identity 324 +12125551212 and two URI identities, sip:alice@example.com and 325 sip:bob@example.com, example: 327 { 328 "dest":{ 329 "tn":["12125551212"], 330 "uri":["sip:alice@example.com", 331 "sip:bob@example.net"] 332 }, 333 "iat":"1443208345", 334 "orig":{"tn":"12155551212"} 335 } 337 4.2.2. "mky" - Media Key claim 339 Some protocols that use PASSporT may also want to protect media 340 security keys delivered within their signaling in order to bind those 341 keys to the identities established in the signaling layers. The 342 "mky" is an optional PASSporT claim defining the assertion of media 343 key fingerprints carried in SDP [RFC4566] via the "a=fingerprint" 344 attribute [RFC4572] Section 5. This claim can support either a 345 single or multiple fingerprints appearing in a single SDP body 346 corresponding to one or more media streams offered. The "mky" claim 347 MUST be formatted in a JSON form including the "alg" and "dig" keys 348 with the corresponding algorithm and hexadecimal values. If there is 349 more than one fingerprint value associated with different media 350 streams in SDP, the fingerprint values MUST be constructed as a JSON 351 array denoted by bracket characters. For the "dig" key value, the 352 hash value MUST be the hexadecimal value without any colons. The 353 "mky" array MUST order the JSON objects containing both "alg" and 354 "dig" key values in lexicographic order of the "alg" string first 355 followed by the corresponding lexicographic order of the "dig" string 356 values. Within each of those objects the JSON keys MUST have "alg" 357 first and "dig" second. 359 An example claim with "mky" claim is as follows: 361 For an SDP offer that includes the following fingerprint values, 363 a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E: 364 5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1 365 a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65 366 :2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2 368 the PASSporT Payload object would be: 370 { 371 "dest":{"uri":["sip:alice@example.com"]}, 372 "iat":"1443208345", 373 "mky":[ 374 { 375 "alg":"sha-256", 376 "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54 377 F17A03A27DF9B07F4619B2" 378 }, 379 { 380 "alg":"sha-256", 381 "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C 382 AB3E4B652E7D463F5442CD54F1" 383 } 384 ], 385 "orig":{"tn":"12155551212"} 386 } 388 5. PASSporT Signature 390 The signature of the PASSporT is created as specified by JWS 391 [RFC7515] Section 5.1 Steps 1 through 6. PASSporT MUST use the JWS 392 Protected Header. For the JWS Payload and the JWS Protected Header, 393 the lexicographic ordering and white space rules described above, and 394 JSON serialization rules in Section 8 of this document MUST be 395 followed. 397 Appendix A of this document has a detailed example of how to follow 398 the steps to create the JWS Signature. 400 JWS [RFC7515] Section 5.1 Step 7 JWS JSON serialization is not 401 supported for PASSporT. 403 JWS [RFC7515] Section 5.1 Step 8 describes the method to create the 404 final JWS Compact Serialization form of the PASSporT Token. 406 6. Compact form of PASSporT 408 For a using protocol of PASSporT, the PASSporT Claims as well as the 409 PASSporT Header may include redundant or default information that 410 could be reconstructed at the destination based on information 411 provided in the signaling protocol transporting the PASSporT object. 412 In this case, it may be advantageous to have a more compact form of 413 PASSporT to save the transmission of the bytes needed to represent 414 the header and claims. 416 We define the compact form of the PASSporT token, in the spirit of 417 form defined in [RFC7515] Appendix F, with the use of '..', two 418 periods to represent the header and claim objects being removed, 419 followed by PASSporT signature as defined in Section 5, and the need 420 for the destination to reconstruct the header and claim objects in 421 order to verify the signature. 423 In order to construct the Compact form of the PASSporT string, the 424 procedure described in Section 5 with the exception of Step 8 425 described in JWS [RFC7515] Section 5.1. This step would be replaced 426 by the following construction of the compact form of PASSporT, 427 '..' || BASE64URL(JWS Signature). 429 The using protocol of the compact form of PASSporT MUST be 430 accompanied by a specification for how the header and claims objects 431 can be reconstructed from information in the signaling protocol being 432 used. 434 6.1. Example Compact form PASSporT Token 436 The compact form of the following example token (with line breaks 437 between period used for readability purposes only) 439 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 440 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 441 . 442 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 443 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 444 . 445 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN 446 CpTzO3QfPOlckGaS6hEck7w 448 would be as follows (with line breaks between period used for 449 readability purposes only) 451 ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN 452 CpTzO3QfPOlckGaS6hEck7w 454 7. Extending PASSporT 456 PASSporT includes the bare minimum set of claims needed to securely 457 assert the originating identity and support the secure properties 458 discussed in various parts of this document. JWT supports a straight 459 forward way to add additional claims by simply adding new claim key 460 pairs. PASSporT can be extended beyond the defined base set of 461 claims to represent other information requiring assertion or 462 validation beyond the originating identity itself as needed. 464 7.1. "ppt" (PASSporT) header parameter 466 Any using protocol can extend the payload of PASSporT with additional 467 JWT claims. JWT claims are managed by an existing IANA registry as 468 defined in [RFC7519] Section 10.1. Implementations of PASSporT MUST 469 support the baseline claims defined in Section 4.2, and MAY support 470 extended claims. If it is necessary for an extension to PASSporT to 471 require that a relying party support a particular extended claim or 472 set of claims in the PASSporT object, it can do so by specifying a 473 "ppt" element for the PASSporT JOSE header. All values of "ppt" need 474 to be defined in a specification which associates the new value of 475 the "ppt" element with the required claims and behaviors. Relying 476 parties MUST fail to validate PASSporT objects containing an 477 unsupported "ppt". 479 Using protocols that carry the compact form of PASSporT, defined in 480 Section 6, instead of the full form MUST use only mandatory 481 extensions signaled with "ppt" - if a using protocol were to add 482 additional optional claims to a PASSporT object it carried in compact 483 form, relying parties would have no way to reconstruct the token. 484 Moreover, using protocols that support the compact form of PASSporT 485 MUST have some field to signal "ppt" to relying parties, as the 486 compact form of PASSporT omits the JOSE header. 488 7.2. Example extended PASSporT header 490 An example header with a PASSporT extension type of "foo" is as 491 follows: 493 { 494 "alg":"ES256", 495 "ppt":"foo", 496 "typ":"passport", 497 "x5u":"https://tel.example.org/passport.cer" 498 } 500 7.3. Extended PASSporT Claims 502 Specifications that define extensions to the PASSporT mechanism MUST 503 explicitly specify what claims they include beyond the base set of 504 claims from this document, the order in which they will appear, and 505 any further information necessary to implement the extension. All 506 extensions MUST include the baseline PASSporT claim elements 507 specified in Section 4; claims may only be appended to the claims 508 object specified; they can never be removed or re-ordered. 509 Specifying new claims follows the baseline JWT procedures ([RFC7519] 510 Section 10.1). Understanding an extension or new claims defined by 511 the extension on the destination verification of the PASSporT token 512 is optional. The creator of a PASSporT object cannot assume that 513 destination systems will understand any given extension. 514 Verification of PASSporT tokens by destination systems that do 515 support an extension may then trigger appropriate application-level 516 behavior in the presence of an extension; authors of extensions 517 should provide appropriate extension-specific guidance to application 518 developers on this point. 520 An example set of extended claims, extending the first example in 521 Section 4.2.1.4 using "bar" as the newly defined claim would be as 522 follows: 524 { 525 "bar":"beyond all recognition" 526 "dest":{"uri":["sip:alice@example.com"]}, 527 "iat":"1443208345", 528 "orig":{"tn":"12155551212"} 529 } 531 8. Deterministic JSON Serialization 533 JSON, as a canonical format, can include spaces and line breaks, and 534 key value pairs can occur in any order. It is therefore a non- 535 deterministic string format. In order to make the digital signature 536 verification work deterministically, the JSON representation of the 537 JWS Protected Header object and JWS Payload object MUST be computed 538 as follows. 540 The JSON object MUST follow the rules for the construction of the 541 thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3 542 Step 1 only. Step 2 should not be performed; as noted in JWK this is 543 still a legal JWK object. 545 The PASSporT header and claim direct members MUST follow the 546 lexicographical ordering rules. Any top level JSON members that 547 contain JSON objects or arrays, such as "dest" or "mky" MUST follow 548 their own lexicographical ordering and whitespace and line break 549 rules for the sub-elements. This includes any header or claims 550 defined in future specifications using PASSporT. 552 8.1. Example PASSport deterministic JSON form 554 This section demonstrate the deterministic JSON serialization for the 555 example PASSporT Payload shown in Section 4.2.1.4. 557 The initial JSON object is shown here: 559 { 560 "dest":{"uri":["sip:alice@example.com"]}, 561 "orig":{"tn":"12155551212"} 562 "iat":"1443208345", 563 "mky":[ 564 { 565 "alg":"sha-256", 566 "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54 567 F17A03A27DF9B07F4619B2" 568 }, 569 { 570 "alg":"sha-256", 571 "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C 572 AB3E4B652E7D463F5442CD54F1" 573 } 574 ], 575 } 577 The parent members of the JSON object are as follows: 579 o "dest" 581 o "orig" 583 o "iat" 585 o "mky" 587 Their lexicographic order is: 589 o "dest" 591 o "iat" 593 o "mky" 595 o "orig" 597 The final constructed deterministic JSON serialization 598 representation, with whitespace and line breaks removed, (with line 599 breaks used for display purposes only) is: 601 {"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky": 602 [{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5 603 4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5 604 40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], 605 "orig":{"tn":"12155551212"}} 607 9. Security Considerations 609 9.1. Avoidance of replay and cut and paste attacks 611 There are a number of security considerations for use of the token 612 for avoidance of replay and cut and paste attacks. PASSporT tokens 613 SHOULD only be sent with application level protocol information (e.g. 614 for SIP an INVITE as defined in [RFC3261]) corresponding to the 615 required fields in the token. A uniqueness of the set of token 616 claims and token signature is constructed using the originating 617 identity being asserted with the 'orig' claim along with the the 618 following two claims: 620 o 'iat' claim should correspond to a date/time the message was 621 originated. It should also be within a relative time that is 622 reasonable for clock drift and transmission time characteristics 623 associated with the application using the PASSporT token. 624 Therefore, validation of the token should consider date and time 625 correlation, which could be influenced by signaling protocol 626 specific use and network time differences. 628 o 'dest' claim is included to prevent the valid re-use of a 629 previously originated message to send to another destination 630 party. 632 9.2. Solution Considerations 634 The use of PASSporT tokens based on the validation of the digital 635 signature and the associated certificate requires consideration of 636 the authentication and authority or reputation of the signer to 637 attest to the identity being asserted. The following considerations 638 should be recognized when using PASSporT: * The use of this token 639 should not, in it's own right, be considered a full solution for 640 absolute non-repudiation of the identity being asserted. * In many 641 applications, the end user the asserted identity represents and 642 signer may not be one in the same. For example, when a service 643 provider signs and validates the token on the behalf of the user 644 consuming the service, the provider MUST have an authenticated and 645 secure relationship with the end user or the device initiating and 646 terminating the communications signaling. * Applications that use 647 PASSporT should ensure the verification of the signature includes the 648 means of verifying the signer is authoritative through the use of an 649 application or service specific set of common trust anchors for the 650 application. 652 10. IANA Considerations 654 10.1. Media Type Registration 656 10.1.1. Media Type Registry Contents Additions Requested 658 This section registers the "application/passport" media type 659 [RFC2046] in the "Media Types" registry in the manner described in 660 [RFC6838], which can be used to indicate that the content is a 661 PASSporT defined JWT and JWS. 663 o Type name: application 665 o Subtype name: passport 667 o Required parameters: n/a 669 o Optional parameters: n/a 671 o Encoding considerations: 8bit; application/passport values outside 672 the US-ASCII range are encoded using percent encoding as described 673 in Section 2.1 of [RFC3986] (some values may be the empty string), 674 each separated from the next by a single period ('.') character. 676 o Security considerations: See the Security Considerations 677 Section of [RFC7515]. 679 o Interoperability considerations: n/a 681 o Published specification: [RFCThis] 683 o Applications that use this media type: STIR and other applications 684 that require identity related assertion 686 o Fragment identifier considerations: n/a 688 o Additional information: 690 Magic number(s): n/a File extension(s): n/a Macintosh file type 691 code(s): n/a 693 o Person & email address to contact for further information: Chris 694 Wendt, chris-ietf@chriswendt.net 696 o Intended usage: COMMON 698 o Restrictions on usage: none 699 o Author: Chris Wendt, chris-ietf@chriswendt.net 701 o Change Controller: IESG 703 o Provisional registration? No 705 10.2. JSON Web Token Claims Registration 707 10.2.1. Registry Contents Additions Requested 709 o Claim Name: "orig" 711 o Claim Description: Originating Identity String 713 o Change Controller: IESG 715 o Specification Document(s): Section 4.2.1 of [RFCThis] 717 o Claim Name: "dest" 719 o Claim Description: Destination Identity String 721 o Change Controller: IESG 723 o Specification Document(s): Section 4.2.1 of [RFCThis] 725 o Claim Name: "mky" 727 o Claim Description: Media Key Fingerprint String 729 o Change Controller: IESG 731 o Specification Document(s): Section 4.2.2 of [RFCThis] 733 10.3. JSON Web Signature and Encryption Header Parameter Registry 735 10.3.1. Registry Contents Additions Requested 737 Header Parameter Name: "ppt" 739 o Header Parameter Description: PASSporT extension identifier 741 o Header Parameter Usage Location(s): JWS 743 o Change Controller: IESG 745 o Specification Document(s): Section 7.1 of [RFCThis] 747 11. Acknowledgements 749 Particular thanks to members of the ATIS and SIP Forum NNI Task Group 750 including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill, 751 Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for 752 their review, ideas, and contributions also thanks to Henning 753 Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark 754 Miller, Ted Hardie, Dave Crocker, Robert Sparks for valuable feedback 755 on the technical and security aspects of the document. Additional 756 thanks to Harsha Bellur for assistance in coding the example tokens. 758 12. References 760 12.1. Normative References 762 [I-D.ietf-stir-rfc4474bis] 763 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 764 "Authenticated Identity Management in the Session 765 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-12 766 (work in progress), September 2016. 768 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 769 Extensions (MIME) Part Two: Media Types", RFC 2046, 770 DOI 10.17487/RFC2046, November 1996, 771 . 773 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 774 Resource Identifier (URI): Generic Syntax", STD 66, 775 RFC 3986, DOI 10.17487/RFC3986, January 2005, 776 . 778 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 779 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 780 July 2006, . 782 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 783 Transport Layer Security (TLS) Protocol in the Session 784 Description Protocol (SDP)", RFC 4572, 785 DOI 10.17487/RFC4572, July 2006, 786 . 788 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 789 Specifications and Registration Procedures", BCP 13, 790 RFC 6838, DOI 10.17487/RFC6838, January 2013, 791 . 793 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 794 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 795 2015, . 797 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 798 DOI 10.17487/RFC7518, May 2015, 799 . 801 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 802 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 803 . 805 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 806 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 807 2015, . 809 12.2. Informative References 811 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 812 A., Peterson, J., Sparks, R., Handley, M., and E. 813 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 814 DOI 10.17487/RFC3261, June 2002, 815 . 817 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 818 Housley, R., and W. Polk, "Internet X.509 Public Key 819 Infrastructure Certificate and Certificate Revocation List 820 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 821 . 823 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 824 Telephone Identity Problem Statement and Requirements", 825 RFC 7340, DOI 10.17487/RFC7340, September 2014, 826 . 828 Appendix A. Example ES256 based PASSporT JWS Serialization and 829 Signature 831 For PASSporT, there will always be a JWS with the following members: 833 o "protected", with the value BASE64URL(UTF8(JWS Protected Header)) 835 o "payload", with the value BASE64URL (JWS Payload) 837 o "signature", with the value BASE64URL(JWS Signature) 838 This example will follow the steps in JWS [RFC7515] Section 5.1, 839 steps 1-6 and 8 and incorporates the additional serialization steps 840 required for PASSporT. 842 Step 1 for JWS references the JWS Payload, an example PASSporT 843 Payload is as follows: 845 { 846 "dest":{"uri":["sip:alice@example.com"]} 847 "iat":"1443208345", 848 "orig":{"tn":"12155551212"} 849 } 851 This would be serialized to the form (with line break used for 852 display purposes only): 854 {"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345", 855 "orig":{"tn":"12155551212"}} 857 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 858 line break used for display purposes only): 860 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 861 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 863 For Step 3, an example PASSporT Protected Header comprising the JOSE 864 Header is as follows: 866 { 867 "alg":"ES256", 868 "typ":"passport", 869 "x5u":"https://cert.example.org/passport.cer" 870 } 872 This would be serialized to the form (with line break used for 873 display purposes only): 875 {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org 876 /passport.cer"} 878 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 879 and encoding produces this value (with line break used for display 880 purposes only): 882 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 883 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 884 Step 5 and Step 6 performs the computation of the digital signature 885 of the PASSporT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 886 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 887 algorithm and the BASE64URL(JWS Signature). 889 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN 890 CpTzO3QfPOlckGaS6hEck7w 892 Step 8 describes how to create the final PASSporT token, 893 concatenating the values in the order Header.Payload.Signature with 894 period ('.') characters. For the above example values this would 895 produce the following (with line breaks between period used for 896 readability purposes only): 898 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 899 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 900 . 901 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 902 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 903 . 904 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN 905 CpTzO3QfPOlckGaS6hEck7w 907 A.1. X.509 Private Key for ES256 Example** 909 -----BEGIN EC PRIVATE KEY----- 910 MHcCAQEEIFeZ1R208QCvcu5GuYyMfG4W7sH4m99/7eHSDLpdYllFoAoGCCqGSM49 911 AwEHoUQDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH78YTU8qLS8I5HLHSSmlATLcs 912 lQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 913 -----END EC PRIVATE KEY----- 915 A.2. X.509 Public Key for ES256 Example** 917 -----BEGIN PUBLIC KEY----- 918 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 919 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 920 -----END PUBLIC KEY----- 922 Authors' Addresses 924 Chris Wendt 925 Comcast 926 One Comcast Center 927 Philadelphia, PA 19103 928 USA 930 Email: chris-ietf@chriswendt.net 931 Jon Peterson 932 Neustar Inc. 933 1800 Sutter St Suite 570 934 Concord, CA 94520 935 US 937 Email: jon.peterson@neustar.biz