idnits 2.17.1 draft-ietf-stir-passport-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 173: '...the "typ" header MUST be the string "p...' RFC 2119 keyword, line 180: '... signatures ES256 MUST be implemented....' RFC 2119 keyword, line 192: '... with the guidance that it MUST be TLS...' RFC 2119 keyword, line 224: '... The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined...' RFC 2119 keyword, line 239: '...orig" and "dest" MUST have claims wher...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 22, 2016) is 2798 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: 'RFC4566' is mentioned on line 310, but not defined ** Obsolete undefined reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: February 23, 2017 Neustar Inc. 6 August 22, 2016 8 Persona Assertion Token 9 draft-ietf-stir-passport-06 11 Abstract 13 This document defines a canonical string object or 'token' for 14 verifying with non-repudiation the author of the token, their 15 authority to author the token and, minimally, the asserted 16 originating identity or persona contained within the token 17 corresponding specifically to the originator of 'personal 18 communications', or any signalled communications between a set of 19 parties with identities. A cryptographic signature is defined to 20 protect the integrity of the information used to identify the 21 originator of a personal communications session (e.g. the telephone 22 number or URI) and verify the assertion of the identity information 23 at the destination. The cryptographic signature is defined with the 24 intention that it can confidently verify the originating persona even 25 when the signature is sent to the destination party over an insecure 26 channel. The Persona Assertion Token (PASSporT) is particularly 27 useful for many personal communications applications over IP networks 28 and other multi-hop interconnection scenarios where the originating 29 and destination parties may not have a direct trusted relationship. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 23, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. PASSporT Token Overview . . . . . . . . . . . . . . . . . . . 3 67 3. PASSporT Components . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. PASSporT Header . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. "typ" (Type) Header Parameter . . . . . . . . . . . . 4 70 3.1.2. "alg" (Algorithm) Header Parameter . . . . . . . . . 4 71 3.1.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 4 72 3.2. PASSporT Payload . . . . . . . . . . . . . . . . . . . . 5 73 3.2.1. JWT defined claims . . . . . . . . . . . . . . . . . 5 74 3.2.1.1. "iat" - Issued At claim . . . . . . . . . . . . . 5 75 3.2.2. PASSporT specific claims . . . . . . . . . . . . . . 5 76 3.2.2.1. Originating and Destination Identity Claims . . . 5 77 3.2.2.2. "mky" - Media Key claim . . . . . . . . . . . . . 7 78 3.3. PASSporT Signature . . . . . . . . . . . . . . . . . . . 8 79 4. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . 8 81 4.2. Extended PASSporT Claims . . . . . . . . . . . . . . . . 9 82 5. Deterministic JSON Serialization . . . . . . . . . . . . . . 9 83 5.1. Example PASSport deterministic JSON form . . . . . . . . 10 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6.1. Avoidance of replay and cut and paste attacks . . . . . . 10 86 6.2. Solution Considerations . . . . . . . . . . . . . . . . . 10 87 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . 11 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 89 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 11 90 7.1.1. Media Type Registry Contents Additions Requested . . 11 91 7.2. JSON Web Token Claims Registration . . . . . . . . . . . 12 92 7.2.1. Registry Contents Additions Requested . . . . . . . . 12 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 96 9.2. Informative References . . . . . . . . . . . . . . . . . 14 97 Appendix A. Example PASSporT JWS Serialization and Signature . . 14 98 A.1. X.509 Private Key Certificate for Example . . . . . . . . 16 99 A.2. X.509 Public Key Certificate for Example . . . . . . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 In today's IP-enabled telecommunications world, there is a growing 105 concern about the ability to trust incoming invitations for 106 communications sessions, including video, voice and messaging. 107 [RFC7340] As an example, modern telephone networks provide the 108 ability to spoof the calling party telephone number for many 109 legitimate purposes including providing network features and services 110 on the behalf of a legitimate telephone number. However, as we have 111 seen, bad actors have taken advantage of this ability for 112 illegitimate and fraudulent purposes meant to trick telephone users 113 to believe they are someone they are not. This problem can be 114 extended to many emerging forms of personal communications. 116 This document defines a method for creating and validating a token 117 that cryptographically verifies an originating identity, or more 118 generally a URI or telephone number representing the originator of 119 personal communications. Through extensions defined in this 120 document, other information relevant to the personal communications 121 can also be added to the token. The goal of PASSporT is to provide a 122 common framework for signing originating identity related information 123 in an extensible way. Additionally, this functionality is 124 independent of any specific personal communications signaling call 125 logic, so that the assertion of originating identity related 126 information can be implemented in a flexible way and can be used in 127 applications including end-to-end applications that require different 128 signaling protocols or gateways between different communications 129 systems. It is anticipated that signaling protocol specific guidance 130 will be provided in other related documents and specifications to 131 specify how to use and transport PASSporT tokens, however this is 132 intentionally out of scope for this document. 134 Note: As of the authoring of this document, 135 [I-D.ietf-stir-rfc4474bis] provides details of how to use PASSporT 136 within SIP signaling for the signing and verification of telephone 137 numbers. 139 2. PASSporT Token Overview 141 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 142 and related specifications define a standard token format that can be 143 used as a way of encapsulating claimed or asserted information with 144 an associated digital signature using X.509 based certificates. JWT 145 provides a set of claims in JSON format that can conveniently 146 accomidate asserted originating identity information and is easily 147 extensible for extension mechanisms defined below. Additionally, JWS 148 provides a path for updating methods and cryptographic algorithms 149 used for the associated digital signatures. 151 3. PASSporT Components 153 The PASSporT is constructed based on JWT [RFC7519] and JWS [RFC7515] 154 specifications. JWS defines the use of JSON data structures in a 155 specified canonical format for signing data corresponding to JOSE 156 header, JWS Payload, and JWS Signature. JWT defines specific set of 157 claims that are represented by specified key value pairs which can be 158 extended with custom keys for specific applications. 160 3.1. PASSporT Header 162 The JWS token header is a JOSE header [RFC7515] that defines the type 163 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.1. "typ" (Type) Header Parameter 170 JWS defines the "typ" (Type) Header Parameter to declare the media 171 type of the 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.1.2. "alg" (Algorithm) Header Parameter 178 For PASSporT, the "alg" should be defined as follows, for the 179 creation and verification of PASSporT tokens and their digital 180 signatures ES256 MUST be implemented. 182 Note that JWA [RFC7518] defines other algorithms that may be utilized 183 or updated in the future depending on cryptographic strength 184 requirements guided by current security best practice. 186 3.1.3. "x5u" (X.509 URL) Header Parameter 188 As defined in JWS, the "x5u" header parameter is used to provide a 189 URI [RFC3986] referring to the resource for the X.509 public key 190 certificate or certificate chain [RFC5280] corresponding to the key 191 used to digitally sign the JWS. Generally this would correspond to 192 an HTTPS or DNSSEC resource with the guidance that it MUST be TLS 193 protected, per JWS spec. 195 An example of the header, would be the following, 197 { 198 "typ":"passport", 199 "alg":"ES256", 200 "x5u":"https://cert.example.org/passport.cer" 201 } 203 3.2. PASSporT Payload 205 The token claims consist of the information which needs to be 206 verified at the destination party. These claims follow the 207 definition of a JWT claim [RFC7519] and be encoded as defined by the 208 JWS Payload [RFC7515]. 210 PASSporT defines the use of a standard JWT defined claim as well as 211 custom claims corresponding to the two parties associated with 212 personal communications, the originator and destination as detailed 213 below. 215 Key values outside the US-ASCII range should be encoded using percent 216 encoding as described in section 2.1 of [RFC3986], case normalized as 217 described in 6.2.2.1 of [RFC3986]. Matching of these values should 218 use string exact match. 220 3.2.1. JWT defined claims 222 3.2.1.1. "iat" - Issued At claim 224 The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined 225 claim Issued At. As defined this should be set to the date and time 226 of the origination of the personal communications. The time value 227 should be of the format defined in [RFC7519] Section 2 NumericDate. 228 This is included for securing the token against replay and cut and 229 paste attacks, as explained further in the security considerations in 230 section 6. 232 3.2.2. PASSporT specific claims 234 3.2.2.1. Originating and Destination Identity Claims 236 PASSporT defines claims that convey the identity of the origination 237 and destination of personal communications. There are two claims 238 that are required for PASSporT, the "orig" and "dest" claims. Both 239 "orig" and "dest" MUST have claims where the key represents an 240 identity type and the value is the identity string, both defined in 241 subsecquent subsections. Currently, these identities can be 242 represented as either telephone numbers or Uniform Resource 243 Indicators (URIs). 245 The "orig" JSON object MUST only have one key value pair representing 246 the asserted identity of any type (currently either "tn" or "uri") of 247 the originator of the personal communications signaling. 249 The "dest" JSON object MUST have at least have one key value pair, 250 but could have multiple identity types (i.e. "tn" and/or "uri") but 251 only one of each. Additionaly, in the case of "dest" only, the 252 identity type key value MUST be an array signaled by standard JSON 253 brackets, even when there is a single identity value in the identity 254 type key value. 256 3.2.2.1.1. "tn" - Telephone Number identity 258 If the originating or destination identity is a telephone number, the 259 key representing the identity MUST be "tn". 261 Telephone Number strings for "tn" MUST be canonicalized according to 262 the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 7.2. 264 3.2.2.1.2. "uri" - URI identity 266 If any of the originating or destination identities is of the form 267 URI, as defined in [RFC3986], the key representing the identity MUST 268 be "uri" URI form of the identity. 270 3.2.2.1.3. Future identity forms 272 We recognize that in the future there may be other standard 273 mechanisms for representing identities. The "orig" and "dest" claims 274 currently support "tn" and "uri" but could be extended in the future 275 to allow for other identity types with new IANA registered unique 276 types to represent these forms. 278 3.2.2.1.4. Examples 280 Single Originator, with telephone number identity +12155551212, to 281 Single Destination, with URI identity 'sip:alice@example.com', 282 example: 284 { 285 "dest":{"uri":["sip:alice@example.com"]}, 286 "iat":"1443208345", 287 "orig":{"tn":"12155551212"} 288 } 290 Single Originator, with telephone number identity +12155551212, to 291 Multiple Destination Identities, with telephone number identity 292 +12125551212 and two URI identities, sip:alice@example.com and 293 sip:bob@example.com, example: 295 { 296 "dest":{ 297 "tn":["12125551212"], 298 "uri":["sip:alice@example.com", 299 "sip:bob@example.net"] 300 }, 301 "iat":"1443208345", 302 "orig":{"tn":"12155551212"} 303 } 305 3.2.2.2. "mky" - Media Key claim 307 Some protocols that use PASSporT convey hashes for media security 308 keys within their signaling in order to bind those keys to the 309 identities established in the signaling layers. One example would be 310 the DTLS-SRTP key fingerprints carried in SDP [RFC4566] via the 311 "a=fingerprint" attribute; multiple instances of that fingerprint may 312 appear in a single SDP body corresponding to media streams offered. 314 The "mky" claim MUST be formated in a JSON form including the 'alg' 315 and 'dig' keys with the corresponding algorithm and hexadecimal 316 values. If there is multiple fingerprint values, for example 317 associated with different media streams in SDP, the fingerprint 318 values MUST be constructed as a JSON array denoted by bracket 319 characters. 321 For the 'dig' key value, the hash value MUST be the hexadecimal value 322 without any colons. 324 An example claim with "mky" claim is as follows: 326 For an SDP offer that includes the following fingerprint values, 328 a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65: 329 2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2 330 a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E: 331 5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1 333 the PASSporT Payload object would be: 335 { 336 "dest":{"uri":["sip:alice@example.com"]}, 337 "iat":"1443208345", 338 "mky":[ 339 { 340 "alg":"sha-256", 341 "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54 342 F17A03A27DF9B07F4619B2" 343 }, 344 { 345 "alg":"sha-256", 346 "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C 347 AB3E4B652E7D463F5442CD54F1" 348 } 349 ], 350 "orig":{"tn":"12155551212"} 351 } 353 3.3. PASSporT Signature 355 The signature of the PASSporT is created as specified by JWS using 356 the private key corresponding to the X.509 public key certificate 357 referenced by the "x5u" header parameter. 359 4. Extending PASSporT 361 PASSporT includes the bare minimum set of claims needed to securely 362 assert the originating identity and support the secure propoerties 363 discussed in various parts of this document. JWT supports a straight 364 forward way to add additional claims by simply adding new claim key 365 pairs. PASSporT can be extended beyond the defined base set of 366 claims to represent other information requiring assertion or 367 validation beyond the originating identity itself as needed. 369 4.1. "ppt" (PASSporT) header parameter 371 For extension of the base set of claims defined in this document, a 372 new JWS header parameter "ppt" MUST be used with a unique string. 373 Any PASSporT extension should be defined in a specification 374 describing the PASSporT extension and the string used in the "ppt" 375 hedaer string that defines any new claims that would extend the base 376 set of claims of PASSporT. 378 An example header with a PASSporT extension type of "foo" is as 379 follows: 381 { 382 "alg":"ES256", 383 "ppt":"foo", 384 "typ":"passport", 385 "x5u":"https://tel.example.org/passport.cer" 386 } 388 4.2. Extended PASSporT Claims 390 Specifications that define extensions to the PASSporT mechanism MUST 391 explicitly specify what claims they include beyond the base set of 392 claims from this document, the order in which they will appear, and 393 any further information necessary to implement the extension. All 394 extensions MUST include the baseline JWT elements specified in 395 Section 3; claims may only be appended to the claims object 396 specified; they can never be removed or re-ordered. Specifying new 397 claims follows the baseline JWT procedures ([RFC7519] Section 10.1). 398 Understanding an extension or new claims defined by the extension on 399 the destination verification of the PASSporT token is optional. The 400 creator of a PASSporT object cannot assume that destination systems 401 will understand any given extension. Verification of PASSporT tokens 402 by destination systems that do support an extension may then trigger 403 appropriate application-level behavior in the presence of an 404 extension; authors of extensions should provide appropriate 405 extension-specific guidance to application developers on this point. 407 5. Deterministic JSON Serialization 409 JSON, as a canonical format, can include spaces, line breaks and key 410 value pairs can occur in any order and therefore makes it, from a 411 string format, non-deterministic. In order to make the digitial 412 signature verification work deterministically, the JSON 413 representation of the PASSporT Header and Claims, particularly if 414 PASSporT is used across multiple signaling environments, specifically 415 the JSON header object and JSON Claim object MUST be computed as 416 follows. 418 The JSON object MUST follow the rules for the construction of the 419 thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3. 420 Each JSON object MUST contain no whitespace or line breaks before or 421 after any syntactic elements and with the required members ordered 422 lexicographically by the Unicode [UNICODE] code points of the member 423 names. 425 In addition, the JSON header and claim members MUST follow the 426 lexicographical ordering and character and string rules defined in 427 [RFC7638] Section 3.3. 429 5.1. Example PASSport deterministic JSON form 431 For the example PASSporT Payload shown in Section 3.2.2.2, the 432 following is the deterministic JSON object form. 434 {"dest":{"uri":["sip:alice@example.com"],"iat": 1443208345,"mky" 435 :[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442 436 CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8 437 2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], 438 "orig":{"tn":"12155551212"}} 440 6. Security Considerations 442 6.1. Avoidance of replay and cut and paste attacks 444 There are a number of security considerations for use of the token 445 for avoidance of replay and cut and paste attacks. PASSporT tokens 446 should be sent with other application level protocol information 447 (e.g. for SIP an INVITE as defined in [RFC3261]). In order to make 448 the token signature unique to a specific origination of personal 449 communications there should be a link between various information 450 provided in the token and information provided by the application 451 level protocol information. This uniqueness specified using the 452 following two claims: 454 o 'iat' claim should correspond to a date/time the message was 455 originated. It should also be within a relative time that is 456 reasonable for clock drift and transmission time characteristics 457 associated with the application using the PASSporT token. 458 Therefore, validation of the token should consider date and time 459 correlation, which could be influenced by signaling protocol 460 specific use and network time differences. 462 o 'dest' claim is included to prevent the valid re-use of a 463 previously originated message to send to another destination 464 party. 466 6.2. Solution Considerations 468 It should be recognized that the use of this token should not, in 469 it's own right, be considered a full solution for absolute non- 470 repudiation of the persona being asserted. This only provides non- 471 repudiation of the signer of PASSporT. If the signer and the persona 472 are not one in the same, which can and often will be the case in 473 telecommunications networks today, protecting the destination party 474 from being spoofed may take some interpretation or additional 475 verification of the link between the PASSporT signature and the 476 persona being asserted. 478 In addition, the telecommunications systems and specifications that 479 use PASSporT should in practice provide mechanisms for: 481 o Managing X.509 certificates and X.509 certificate chains to an 482 authorized trust anchor that can be a trusted entity to all 483 participants in the telecommunications network 485 o Accounting for entities that may route calls from other peer or 486 interconnected telecommunications networks that are not part of 487 the "trusted" communications network or may not be following the 488 usage of PASSporT or the profile of PASSporT appropriate to that 489 network 491 o Following best practices around management and security of X.509 492 certificates 494 6.3. Privacy Considerations 496 Because PASSporT explicitly includes claims of identifiers of parties 497 involved in communications, date and times, and potentially other 498 call detail, care should be taken outside of traditional protected or 499 private telephony communications paths where there may be concerns 500 about exposing information to either unintended or illegitimate 501 actors. These identifiers are often exposed through many 502 communications signaling protocols as of today, but appropriate 503 precautions should be taken. 505 7. IANA Considerations 507 7.1. Media Type Registration 509 7.1.1. Media Type Registry Contents Additions Requested 511 This section registers the "application/passport" media type 512 [RFC2046] in the "Media Types" registry in the manner described in 513 [RFC6838], which can be used to indicate that the content is a 514 PASSporT defined JWT and JWS. 516 o Type name: application 518 o Subtype name: passport 520 o Required parameters: n/a 522 o Optional parameters: n/a 524 o Encoding considerations: 8bit; application/passport values outside 525 the US-ASCII range are encoded using percent encoding as described 526 in section 2.1 of RFC 3986 (some values may be the empty string), 527 each separated from the next by a single period ('.') character. 529 o Security considerations: See the Security Considerations section 530 of RFC 7515. 532 o Interoperability considerations: n/a 534 o Published specification: draft-ietf-stir-passport-05 536 o Applications that use this media type: STIR and other applications 537 that require identity related assertion 539 o Fragment identifier considerations: n/a 541 o Additional information: 543 * Magic number(s): n/a 545 * File extension(s): n/a 547 * Macintosh file type code(s): n/a 549 o Person and email address to contact for further information: Chris 550 Wendt, chris-ietf@chriswendt.net 552 o Intended usage: COMMON 554 o Restrictions on usage: none 556 o Author: Chris Wendt, chris-ietf@chriswendt.net 558 o Change Controller: IESG 560 o Provisional registration? No 562 7.2. JSON Web Token Claims Registration 564 7.2.1. Registry Contents Additions Requested 566 o Claim Name: "orig" 568 o Claim Description: Originating Identity String 570 o Change Controller: IESG 572 o Specification Document(s): Section 3.2 of draft-ietf-stir- 573 passport-05 575 o Claim Name: "dest" 577 o Claim Description: Destination Identity String 579 o Change Controller: IESG 581 o Specification Document(s): Section 3.2 of draft-ietf-stir- 582 passport-05 584 o Claim Name: "mky" 586 o Claim Description: Media Key Fingerprint String 588 o Change Controller: IESG 590 o Specification Document(s): Section 3.2 of draft-ietf-stir- 591 passport-05 593 8. Acknowledgements 595 Particular thanks to members of the ATIS and SIP Forum NNI Task Group 596 including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill, 597 Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for 598 their review, ideas, and contributions also thanks to Henning 599 Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark 600 Miller, and Ted Hardie for valuable feedback on the technical and 601 security aspects of the document. Additional thanks to Harsha Bellur 602 for assistance in coding the example tokens. 604 9. References 606 9.1. Normative References 608 [I-D.ietf-stir-rfc4474bis] 609 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 610 "Authenticated Identity Management in the Session 611 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-10 612 (work in progress), July 2016. 614 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 615 Extensions (MIME) Part Two: Media Types", RFC 2046, 616 DOI 10.17487/RFC2046, November 1996, 617 . 619 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 620 Resource Identifier (URI): Generic Syntax", STD 66, 621 RFC 3986, DOI 10.17487/RFC3986, January 2005, 622 . 624 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 625 Specifications and Registration Procedures", BCP 13, 626 RFC 6838, DOI 10.17487/RFC6838, January 2013, 627 . 629 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 630 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 631 2015, . 633 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 634 DOI 10.17487/RFC7518, May 2015, 635 . 637 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 638 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 639 . 641 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 642 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 643 2015, . 645 [UNICODE] "The Unicode Consortium, "The Unicode Standard"", 646 . 648 9.2. Informative References 650 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 651 A., Peterson, J., Sparks, R., Handley, M., and E. 652 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 653 DOI 10.17487/RFC3261, June 2002, 654 . 656 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 657 Housley, R., and W. Polk, "Internet X.509 Public Key 658 Infrastructure Certificate and Certificate Revocation List 659 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 660 . 662 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 663 Telephone Identity Problem Statement and Requirements", 664 RFC 7340, DOI 10.17487/RFC7340, September 2014, 665 . 667 Appendix A. Example PASSporT JWS Serialization and Signature 669 For PASSporT, there will always be a JWS with the following members: 671 o "protected", with the value BASE64URL(UTF8(JWS Protected Header)) 672 o "payload", with the value BASE64URL (JWS Payload) 674 o "signature", with the value BASE64URL(JWS Signature) 676 Note: there will never be a JWS Unprotected Header for PASSporT. 678 First, an example PASSporT Protected Header is as follows: 680 { 681 "typ":"passport", 682 "alg":"ES256", 683 "x5u":"https://cert.example.org/passport.cer" 684 } 686 This would be serialized to the form: 688 {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ 689 passport.cer"} 691 Encoding this with UTF8 and BASE64 encoding produces this value: 693 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 694 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 696 Second, an example PASSporT Payload is as follows: 698 { 699 "dest":{"uri":["sip:alice@example.com"]} 700 "iat":"1443208345", 701 "orig":{"tn":"12155551212"} 702 } 704 This would be serialized to the form: 706 {"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345", 707 "orig":{"tn":"12155551212"}} 709 Encoding this with the UTF8 and BASE64 encoding produces this value: 711 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd 712 CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 714 Computing the digital signature of the PASSporT Signing Input 715 ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS 716 Payload)) 718 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso 719 jNCpTzO3QfPOlckGaS6hEck7w 721 The final PASSporT token is produced by concatenating the values in 722 the order Header.Payload.Signature with period (',') characters. For 723 the above example values this would produce the following: 725 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly 726 9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 727 . 728 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd 729 CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 730 . 731 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso 732 jNCpTzO3QfPOlckGaS6hEck7w 734 A.1. X.509 Private Key Certificate for Example 736 -----BEGIN EC PRIVATE KEY----- 737 MHcCAQEEIFeZ1R208QCvcu5GuYyMfG4W7sH4m99/7eHSDLpdYllFoAoGCCqGSM49 738 AwEHoUQDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH78YTU8qLS8I5HLHSSmlATLcs 739 lQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 740 -----END EC PRIVATE KEY----- 742 A.2. X.509 Public Key Certificate for Example 744 -----BEGIN PUBLIC KEY----- 745 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 746 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 747 -----END PUBLIC KEY----- 749 Authors' Addresses 751 Chris Wendt 752 Comcast 753 One Comcast Center 754 Philadelphia, PA 19103 755 USA 757 Email: chris-ietf@chriswendt.net 759 Jon Peterson 760 Neustar Inc. 761 1800 Sutter St Suite 570 762 Concord, CA 94520 763 US 765 Email: jon.peterson@neustar.biz