idnits 2.17.1 draft-ietf-stir-passport-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 179: '...the "typ" header MUST minimally includ...' RFC 2119 keyword, line 187: '... signatures ES256 MUST be implemented....' RFC 2119 keyword, line 201: '...ce with the guidance that it MUST be a...' RFC 2119 keyword, line 225: '... The JSON claim MUST include the "iat" [RFC7519] defined claim issued...' RFC 2119 keyword, line 248: '...rig" JSON object MUST only have one ke...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2016) is 2835 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-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 1 error (**), 0 flaws (~~), 3 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: January 23, 2017 Neustar Inc. 6 July 22, 2016 8 Persona Assertion Token 9 draft-ietf-stir-passport-05 11 Abstract 13 This document defines a token format for verifying with non- 14 repudiation the sender of and authorization to send information 15 related to the originator of personal communications. A 16 cryptographic signature is defined to protect the integrity of the 17 information used to identify the originator of a personal 18 communications session (e.g. the telephone number or URI) and verify 19 the accuracy of this information at the destination. The 20 cryptographic signature is defined with the intention that it can 21 confidently verify the originating persona even when the signature is 22 sent to the destination party over an unsecure channel. The Persona 23 Assertion Token (PASSporT) is particularly useful for many personal 24 communications applications over IP networks and other multi-hop 25 interconnection scenarios where the originating and destination 26 parties may not have a direct trusted relationship. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 23, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Token Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. PASSporT Definition . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. PASSporT Header . . . . . . . . . . . . . . . . . . . . . 4 66 3.1.1. "typ" (Type) Header Parameter . . . . . . . . . . . . 4 67 3.1.2. "alg" (Algorithm) Header Parameter . . . . . . . . . 5 68 3.1.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 5 69 3.2. PASSporT Payload . . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. JWT defined claims . . . . . . . . . . . . . . . . . 5 71 3.2.1.1. "iat" - Issued at claim . . . . . . . . . . . . . 5 72 3.2.2. PASSporT specific claims . . . . . . . . . . . . . . 6 73 3.2.2.1. Originating and Destination Identity Claims . . . 6 74 3.2.2.2. "mky" - Media Key claim . . . . . . . . . . . . . 7 75 3.3. PASSporT Signature . . . . . . . . . . . . . . . . . . . 8 76 4. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 8 77 4.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . 8 78 4.2. Extended PASSporT Claims . . . . . . . . . . . . . . . . 9 79 5. Deterministic JSON Serialization . . . . . . . . . . . . . . 9 80 5.1. Example PASSport deterministic JSON form . . . . . . . . 10 81 6. Human Readability . . . . . . . . . . . . . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7.1. Avoidance of replay and cut and paste attacks . . . . . . 10 84 7.2. Solution Considerations . . . . . . . . . . . . . . . . . 11 85 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 11 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 11 88 8.1.1. Media Type Registry Contents Additions Requested . . 11 89 8.2. JSON Web Token Claims Registration . . . . . . . . . . . 13 90 8.2.1. Registry Contents Additions Requested . . . . . . . . 13 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 10.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Appendix A. Example PASSporT JWS Serialization and Signature . . 15 96 A.1. X.509 Private Key Certificate for Example . . . . . . . . 16 97 A.2. X.509 Public Key Certificate for Example . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 In today's IP-enabled telecommunications world, there is a growing 103 concern about the ability to trust incoming invitations for 104 communications sessions, including video, voice and messaging. 105 [RFC7340] As an example, modern telephone networks provide the 106 ability to spoof the calling party telephone number for many 107 legitimate purposes including providing network features and services 108 on the behalf of a legitimate telephone number. However, as we have 109 seen, bad actors have taken advantage of this ability for 110 illegitimate and fraudulent purposes meant to trick telephone users 111 to believe they are someone they are not. This problem can be 112 extended to many emerging forms of personal communications. 114 This document defines a common method for creating and validating a 115 token that cryptographically verifies an originating identity, or 116 more generally a URI or application specific identity string 117 representing the originator of personal communications. Through 118 extended profiles other information relevant to the personal 119 communications can also be attached to the token. The primary goal 120 of PASSporT is to provide a common framework for signing persona 121 related information in an extensible way. A secondary goal is to 122 provide this functionality independent of any specific personal 123 communications signaling call logic, so that creation and 124 verification of persona information can be implemented in a flexible 125 way and can be used in many personal communications applications 126 including end-to-end applications that require different signaling 127 protocols. It is anticipated that signaling protocol specific 128 guidance will be provided in other related documents and 129 specifications to specify how to use and transport PASSporT tokens, 130 however this is intentionally out of scope for this document. 132 Note: As of the authoring of this document, 133 [I-D.ietf-stir-rfc4474bis] provides details of how to use PASSporT 134 within SIP signaling for the signing and verification of telephone 135 numbers. 137 2. Token Overview 139 Tokens are a convenient way of encapsulating information with 140 associated digital signatures. They are used in many applications 141 that require authentication, authorization, encryption, non- 142 repudiation and other use cases. JSON Web Token (JWT) [RFC7519] and 143 JSON Web Signature (JWS) [RFC7515] are designed to provide a compact 144 form for many of these purposes and define a specific method and 145 syntax for signing a specific set of information or "claims" within 146 the token and therefore providing an extensible set of claims. 147 Additionally, JWS provides extensible mechanisms for specifying the 148 method and cryptographic algorithms used for the associated digital 149 signatures. 151 3. PASSporT Definition 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 An example of the header for the case of an ECDSA P-256 digital 166 signature would be the following, 168 { 169 "typ":"passport", 170 "alg":"ES256", 171 "x5u":"https://cert.example.org/passport.cer" 172 } 174 3.1.1. "typ" (Type) Header Parameter 176 JWS defines the "typ" (Type) Header Parameter to declare the media 177 type of the JWS. 179 For PASSporT Token the "typ" header MUST minimally include and begin 180 with "passport". This represents that the encoded token is a JWT of 181 type passport. 183 3.1.2. "alg" (Algorithm) Header Parameter 185 For PASSporT, the "alg" should be defined as follows, for the 186 creation and verification of PASSporT tokens and their digital 187 signatures ES256 MUST be implemented. 189 Note that JWA [RFC7518] defines other algorithms that may be utilized 190 or updated in the future depending on cryptographic strength 191 requirements guided by current security best practice. 193 3.1.3. "x5u" (X.509 URL) Header Parameter 195 As defined in JWS, the "x5u" header parameter is used to provide a 196 URI [RFC3986] referring to the resource for the X.509 public key 197 certificate or certificate chain [RFC5280] corresponding to the key 198 used to digitally sign the JWS. Note: The definition of what the URI 199 represents in terms of the actor serving the X.509 public key is out 200 of scope of this document. However, generally this would correspond 201 to an HTTPS or DNSSEC resource with the guidance that it MUST be a 202 TLS protected, per JWS spec. 204 3.2. PASSporT Payload 206 The token payload claims should consist of the information which 207 needs to be verified at the destination party. This claim should 208 correspond to a JWT claim [RFC7519] and be encoded as defined by the 209 JWS Payload [RFC7515] 211 The PASSporT defines the use of a number of standard JWT defined 212 headers as well as two new custom headers corresponding to the two 213 parties associated with personal communications, the originator and 214 terminator. These headers or key value pairs are detailed below. 216 Key values outside the US-ASCII range should be encoded using percent 217 encoding as described in section 2.1 of RFC 3986, case normalized as 218 described in 6.2.2.1 of [RFC3986]. Matching of these values should 219 use string exact match. 221 3.2.1. JWT defined claims 223 3.2.1.1. "iat" - Issued at claim 225 The JSON claim MUST include the "iat" [RFC7519] defined claim issued 226 at. As defined this should be set to a date cooresponding to the 227 origination of the personal communications. The time value should be 228 of the format defined in [RFC7519] Section 2 NumericDate. This is 229 included for securing the token against replay and cut and paste 230 attacks, as explained further in the security considerations in 231 section 7. 233 3.2.2. PASSporT specific claims 235 3.2.2.1. Originating and Destination Identity Claims 237 Baseline PASSporT defines claims that convey the identity of the 238 origination and destination of personal communications. There are 239 two claims that are required for PASSporT, the "orig" and "dest" 240 claims. Both "orig" and "dest" should have values that are JSON 241 objects that include identities represented by key value pairs, where 242 the key represents an identity type and the value is the identity 243 string. Currently, these identities can be represented as either 244 telephone numbers or Uniform Resource Indicators (URIs). The 245 definition of how telephone numbers or URIs and examples are provided 246 below. 248 The "orig" JSON object MUST only have one key value pair representing 249 the asserted identity of any type (currently either "tn" or "uri") of 250 the originator of the personal communications signaling. 252 The "dest" JSON object MUST have at least have one key value pair, 253 but could have multiple identity types (i.e. "tn" and/or "uri") but 254 only one of each. Additionaly, in the case of "dest" only, the 255 identity type key value MUST be an array signaled by standard JSON 256 brackets, even when there is a single identity value in the identity 257 type key value. 259 3.2.2.1.1. "tn" - Telephone Number identity 261 If the originating or destination identity is a telephone number, the 262 key representing the identity should be "tn". 264 Telephone Number strings for "tn" MUST be canonicalized according to 265 the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 7.2. 267 3.2.2.1.2. "uri" - URI identity 269 If any of the originating or destination identities is of the form 270 URI, as defined in [RFC3986], the key representing the identity 271 should be "uri" URI form of the identity. 273 3.2.2.1.3. Future identity forms 275 We recognize that in the future there may be other standard 276 mechanisms for representing identities. The "orig" and "dest" JSON 277 objects with "tn" and "uri" allow for other identity types with 278 unique keys to represent these forms. 280 3.2.2.1.4. Examples 282 Single Originator to Single Destination example: 284 { 285 "dest":{"uri":["sip:alice@example.com"]}, 286 "iat":"1443208345", 287 "orig":{"tn":"12155551212"} 288 } 290 Single Originator to Multiple Destination Identities example: 292 { 293 "dest":{ 294 "tn":["12125551212"], 295 "uri":["sip:alice@example.com", 296 "sip:bob@example.net"] 297 }, 298 "iat":"1443208345", 299 "orig":{"tn":"12155551212"} 300 } 302 3.2.2.2. "mky" - Media Key claim 304 Some protocols that use PASSporT convey hashes for media security 305 keys within their signaling in order to bind those keys to the 306 identities established in the signaling layers. One example would be 307 the DTLS-SRTP key fingerprints carried in SDP via the "a=fingerprint" 308 attribute; multiple instances of that fingerprint may appear in a 309 single SDP body corresponding to difference media streams offered. 310 The "mky" value of PASSporT contains a hexadecimal key presentation 311 of any hash(es) necessary to establish media security via DTLS-SRTP. 312 This mky value should be formated in a JSON form including the 'alg' 313 and 'dig' keys with the corresponding algorithm and hexadecimal 314 values. Note that per guidance of Section 5 of this document any 315 whitespace and line feeds must be removed. If there is multiple 316 fingerprint values, more than one, the fingerprint values should be 317 constructed as a JSON array denoted by bracket characters. For the 318 'dig' key value, the hash value should be the hexadecimal value 319 without any colons, in order to provide a more efficient, compact 320 form to be encoded in PASSporT token claim. 322 An example claim with "mky" claim is as follows: 324 For an SDP offer that includes the following fingerprint values, 325 a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65: 326 2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2 327 a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E: 328 5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1 330 the PASSporT Payload object would be: 332 { 333 "dest":{"uri":["sip:alice@example.com"]}, 334 "iat":"1443208345", 335 "mky":[ 336 { 337 "alg":"sha-256", 338 "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54 339 F17A03A27DF9B07F4619B2" 340 }, 341 { 342 "alg":"sha-256", 343 "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C 344 AB3E4B652E7D463F5442CD54F1" 345 } 346 ], 347 "orig":{"tn":"12155551212"} 348 } 350 3.3. PASSporT Signature 352 The signature of the PASSporT is created as specified by JWS using 353 the private key corresponding to the X.509 public key certificate 354 referenced by the "x5u" header parameter. 356 4. Extending PASSporT 358 PASSporT represents the bare minimum set of claims needed to assert 359 the originating identity and support the secure propoerties discussed 360 in various parts of this document, however there will certainly be 361 both new uses and ways of extending the application and usage of 362 PASSPorT that requires the ability to extend the defined base set of 363 claims to represent other information requiring assertion or 364 validation beyond the identity itself. 366 4.1. "ppt" (PASSporT) header parameter 368 For the extension of the base set of claims defined in this document, 369 a new JWS header parameter "ppt" MUST be used with a string that 370 uniquely identifies and points to a profile specification that 371 defines any new claims that would extend the base set of claims of 372 PASSporT. 374 An example header with an extended PASSporT profile of "foo" is as 375 follows: 377 { 378 "alg":"ES256", 379 "ppt":"foo", 380 "typ":"passport", 381 "x5u":"https://tel.example.org/passport.cer" 382 } 384 4.2. Extended PASSporT Claims 386 Future specifications that define such extensions to the PASSporT 387 mechanism MUST explicitly designate what claims they include beyond 388 the base set of claims from this document, the order in which they 389 will appear, and any further information necessary to implement the 390 extension. All extensions MUST incorporate the baseline JWT elements 391 specified in Section 3; claims may only be appended to the claims 392 object specified; they can never be subtracted or re-ordered. 393 Specifying new claims follows the baseline JWT procedures ([RFC7519] 394 Section 10.1). Note that understanding an extension as a verifier is 395 always optional for compliance with this specification (though future 396 specifications or profiles for deployment environments may make other 397 "ppt" values mandatory). The creator of a PASSporT object cannot 398 assume that verifiers will understand any given extension. Verifiers 399 that do support an extension may then trigger appropriate 400 application-level behavior in the presence of an extension; authors 401 of extensions should provide appropriate extension-specific guidance 402 to application developers on this point. 404 5. Deterministic JSON Serialization 406 In order to provide a deterministic representation of the PASSporT 407 Header and Claims, particularly if PASSporT is used across multiple 408 signaling environments, the JSON header object and JSON Claim object 409 MUST be computed as follows. 411 The JSON object MUST follow the rules for the construction of the 412 thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3. 413 Each JSON object MUST contain no whitespace or line breaks before or 414 after any syntactic elements and with the required members ordered 415 lexicographically by the Unicode [UNICODE] code points of the member 416 names. 418 In addition, the JSON header and claim members MUST follow the 419 lexicographical ordering and character and string rules defined in 420 [RFC7638] Section 3.3. 422 5.1. Example PASSport deterministic JSON form 424 For the example PASSporT Payload shown in Section 3.2.2.2, the 425 following is the deterministic JSON object form. 427 {"dest":{"uri":["sip:alice@example.com"],"iat": 1443208345,"mky" 428 :[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442 429 CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8 430 2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], 431 "orig":{"tn":"12155551212"}} 433 6. Human Readability 435 JWT [RFC7519] and JWS [RFC7515] are defined to use Base64 and/or UTF8 436 encoding to the Header, Payload, and Signature sections. However, 437 many personal communications protocols, such as SIP and XMPP, use a 438 "human readable" format to allow for ease of use and ease of 439 operational debugging and monitoring. As such, specifications using 440 PASSporT may provide guidance on whether Base64 encoding or plain 441 text will be used for the construction of the PASSporT Header and 442 Claim sections. 444 7. Security Considerations 446 7.1. Avoidance of replay and cut and paste attacks 448 There are a number of security considerations for use of the token 449 for avoidance of replay and cut and paste attacks. PASSporT tokens 450 must be sent along with other application level protocol information 451 (e.g. for SIP an INVITE as defined in [RFC3261]). There should be a 452 link between various information provided in the token and 453 information provided by the application level protocol information. 455 These would include: 457 o "iat" claim should closely correspond to a date/time the message 458 was originated. It should also be within a relative delta time 459 that is reasonable for clock drift and transmission time 460 characteristics associated with the application using the PASSporT 461 token. 463 o "dest" claim is included to prevent the ability to use a 464 previously originated message to send to another destination party 466 7.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 7.3. Privacy Considerations 496 Because PASSporT explicity includes claims of identitifiers of 497 parties involved in communications, times, and potentially other call 498 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 illegitimately 501 intented actors. These identifiers are often exposed through many 502 communications signaling protocols as of today, but appropriate 503 precautions should be taken. 505 8. IANA Considerations 507 8.1. Media Type Registration 509 8.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 514 [RFC6838], which can be used to indicate that the content is a 515 PASSporT defined JWT and JWS. 517 o Type name: application 519 o Subtype name: passport 521 o Required parameters: n/a 523 o Optional parameters: n/a 525 o Encoding considerations: 8bit; application/passport values outside 526 the US-ASCII range are encoded using percent encoding as described 527 in section 2.1 of RFC 3986 (some values may be the empty string), 528 each separated from the next by a single period ('.') character. 530 o Security considerations: See the Security Considerations section 531 of RFC 7515. 533 o Interoperability considerations: n/a 535 o Published specification: draft-ietf-stir-passport-05 537 o Applications that use this media type: STIR and other applications 538 that require identity related assertion 540 o Fragment identifier considerations: n/a 542 o Additional information: 544 * Magic number(s): n/a 546 * File extension(s): n/a 548 * Macintosh file type code(s): n/a 550 o Person and email address to contact for further information: Chris 551 Wendt, chris-ietf@chriswendt.net 553 o Intended usage: COMMON 555 o Restrictions on usage: none 557 o Author: Chris Wendt, chris-ietf@chriswendt.net 559 o Change Controller: IESG 561 o Provisional registration? No 563 8.2. JSON Web Token Claims Registration 565 8.2.1. Registry Contents Additions Requested 567 o Claim Name: "orig" 569 o Claim Description: Originating Identity String 571 o Change Controller: IESG 573 o Specification Document(s): Section 3.2 of draft-ietf-stir- 574 passport-05 576 o Claim Name: "dest" 578 o Claim Description: Destination Identity String 580 o Change Controller: IESG 582 o Specification Document(s): Section 3.2 of draft-ietf-stir- 583 passport-05 585 o Claim Name: "mky" 587 o Claim Description: Media Key Fingerprint String 589 o Change Controller: IESG 591 o Specification Document(s): Section 3.2 of draft-ietf-stir- 592 passport-05 594 9. Acknowledgements 596 Particular thanks to members of the ATIS and SIP Forum NNI Task Group 597 including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill, 598 Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for 599 their review, ideas, and contributions also thanks to Henning 600 Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark 601 Miller, and Ted Hardie for valuable feedback on the technical and 602 security aspects of the document. Additional thanks to Harsha Bellur 603 for assistance in coding the example tokens. 605 10. References 606 10.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 10.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)) 673 o "payload", with the value BASE64URL (JWS Payload) 675 o "signature", with the value BASE64URL(JWS Signature) 677 Note: there will never be a JWS Unprotected Header for PASSporT. 679 First, an example PASSporT Protected Header is as follows: 681 { 682 "typ":"passport", 683 "alg":"ES256", 684 "x5u":"https://cert.example.org/passport.cer" 685 } 687 This would be serialized to the form: 689 {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ 690 passport.cer"} 692 Encoding this with UTF8 and BASE64 encoding produces this value: 694 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 695 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 697 Second, an example PASSporT Payload is as follows: 699 { 700 "dest":{"uri":["sip:alice@example.com"]} 701 "iat":"1443208345", 702 "orig":{"tn":"12155551212"} 703 } 705 This would be serialized to the form: 707 {"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345", 708 "orig":{"tn":"12155551212"}} 710 Encoding this with the UTF8 and BASE64 encoding produces this value: 712 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd 713 CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 715 Computing the digital signature of the PASSporT Signing Input 716 ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS 717 Payload)) 719 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso 720 jNCpTzO3QfPOlckGaS6hEck7w 722 The final PASSporT token is produced by concatenating the values in 723 the order Header.Payload.Signature with period (',') characters. For 724 the above example values this would produce the following: 726 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly 727 9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 728 . 729 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhd 730 CI6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 731 . 732 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYso 733 jNCpTzO3QfPOlckGaS6hEck7w 735 A.1. X.509 Private Key Certificate for Example 737 -----BEGIN EC PRIVATE KEY----- 738 MHcCAQEEIFeZ1R208QCvcu5GuYyMfG4W7sH4m99/7eHSDLpdYllFoAoGCCqGSM49 739 AwEHoUQDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH78YTU8qLS8I5HLHSSmlATLcs 740 lQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 741 -----END EC PRIVATE KEY----- 743 A.2. X.509 Public Key Certificate for Example 745 -----BEGIN PUBLIC KEY----- 746 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH 747 78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g== 748 -----END PUBLIC KEY----- 750 Authors' Addresses 752 Chris Wendt 753 Comcast 754 One Comcast Center 755 Philadelphia, PA 19103 756 USA 758 Email: chris-ietf@chriswendt.net 760 Jon Peterson 761 Neustar Inc. 762 1800 Sutter St Suite 570 763 Concord, CA 94520 764 US 766 Email: jon.peterson@neustar.biz