idnits 2.17.1 draft-ietf-stir-passport-divert-01.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 is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2017) is 2369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 321, but not defined == Unused Reference: 'I-D.ietf-stir-oob' is defined on line 345, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 == Outdated reference: A later version (-07) exists of draft-ietf-stir-oob-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Informational October 30, 2017 5 Expires: May 3, 2018 7 PASSporT Extension for Diverted Calls 8 draft-ietf-stir-passport-divert-01.txt 10 Abstract 12 This document extends PASSporT, which conveys cryptographically- 13 signed information about the people involved in personal 14 communications, to include an indication that a call has been 15 diverted from its original destination to a new one. This 16 information can greatly improve the decisions made by verification 17 services in call forwarding scenarios. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3 56 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Authentication Service Behavior . . . . . . . . . . . . . 5 58 4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 59 5. Using 'div' in STIR out-of-band . . . . . . . . . . . . . . . 6 60 6. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 10. Informative References . . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 PASSporT [I-D.ietf-stir-passport] is a token format based on JWT 70 [RFC7519] for conveying cryptographically-signed information about 71 the people involved in personal communications; it is used with STIR 72 [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the 73 identity of the participants in real-time communications established 74 via a protocol like SIP. This specification extends PASSporT to 75 include an indication that a call has been diverted from its 76 originally destination to a new one. 78 Although the STIR problem statement [RFC7340] is focused on 79 preventing the impersonation of the caller's identity, which is a 80 common enabler for threats such as robocalling and voicemail hacking 81 on the telephone network today, it also provides a signature over the 82 called number as the authentication service sees it. As 83 [I-D.ietf-stir-rfc4474bis] Section 12.1 describes, this protection 84 over the contents of the To header field is intended to prevent a 85 class of cut-and-paste attacks. If Alice calls Bob, for example, Bob 86 might attempt to cut-and-paste the Identity header field in Alice's 87 INVITE into a new INVITE that Bob sends to Carol, and thus be able to 88 fool Carol into thinking the call came from Alice and not Bob. With 89 the signature over the To header field value, the INVITE Carol sees 90 will clearly have been destined originally for Bob, and thus Carol 91 can view the INVITE as suspect. 93 However, as [I-D.ietf-stir-rfc4474bis] Section 12.1.1 points out, it 94 is difficult for Carol to confirm or reject these suspicions based on 95 the information she receives from the baseline PASSporT object. The 96 common "call forwarding" service serves as a good example of the fact 97 that the original called party number is not always the number to 98 which a call is delivered. The address in the To header field value 99 of SIP requests is not supposed to change, accordingly to baseline 100 [RFC3261], as it is the Request-URI that is supposed to be updated 101 when a call is retargeted, but practically speaking some operational 102 environments do alter the To header field. There are a number of 103 potential ways for intermediaries to indicate that such a forwarding 104 operating has taken place. The History-Info header field [RFC7044] 105 was created to store the Request-URIs that are discarded by a call in 106 transit. The SIP Diversion header field [RFC5806], though historic, 107 is still used for this purpose by some operators today. Neither of 108 these header fields provide any cryptographic assurance of secure 109 redirection, and they can both capture minor syntactical changes in 110 URIs that do not reflect a change to the actual target of a call. 112 This specification therefore extends PASSporT with an explicit 113 indication that original called number in PASSporT no longer reflects 114 the destination to which a call is likely to be delivered. 115 Verification services and the relying parties who make authorization 116 decisions about communications may use this indication to confirm 117 that a legitimate retargeting of the call has taken place, rather 118 than a cut-and-paste attack. 120 2. Terminology 122 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 124 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 125 described in [RFC2119]. 127 3. PASSporT 'div' Claim 129 This specification defines a new JSON Web Token claim for "div" which 130 indicates a previous destination for a call during its routing 131 process. When a retargeting entity receives a call signed with a 132 PASSporT, it may act as an authentication service and create a new 133 PASSporT containing the "div" claim to attach to the call (without 134 removing the original PASSporT). Note that a new PASSporT is only 135 necessary when the cannical form of the "dest" identifier (per the 136 canonicalization procedures in [I-D.ietf-stir-rfc4474bis] Section 8) 137 changes due to this retargeting. "div" is typically populated with a 138 destination address found in the "dest" field of PASSporT received by 139 the retargeting entity. These new PASSporT generated by retargeting 140 entities MUST include the "div" PASSporT type, and an "x5u" field 141 pointing to a credential that the retargeting entity controls. The 142 new PASSporT will look as follows: 144 { "typ":"passport", 145 "ppt":"div", 146 "alg":"ES256", 147 "x5u":"https://www.example.com/cert.pkx" } 149 A PASSporT claims object containing "div" is populated with a 150 modification of the original token before the call was retargeted: at 151 a high level, the original identifier for the called party in the 152 "dest" array will become the "div" claim in the new PASSporT. If the 153 "dest" array of the original PASSporT contains multiple identifiers, 154 the retargeting entity MUST select only one them to occupy the "div" 155 field in the new PASSporT. and in particular, it MUST select an 156 identifier that is within the scope of the credential that the 157 retargeting entity will specify in the "x5u" of the PASSporT header 158 (as described below). 160 The new target for the call selected by the retargeting entity 161 becomes the value of the "dest" array of the new PASSporT. The 162 "orig" value MUST be copied into the new PASSporT from the original 163 PASSporT received by the retargeting entity. The regargeting entity 164 SHOULD retain the "iat" value from the original PASSporT, though if 165 in the underlying signaling protocol (e.g. SIP) the retargeting 166 entity changes the date and time information in the retargeted 167 request, the new PASSporT should instead reflect that date and time. 168 No other extension claims should be copied from the original PASSporT 169 to the "div" PASSporT. 171 So, for an original PASSporT of the form: 173 { "orig":{"tn":"12155551212"}, 174 "dest":{"tn":"12155551213"}, 175 "iat":1443208345 } 177 If the retargeting entity is changing the target from 12155551213 to 178 12155551214, the new PASSporT with "div" would look as follows: 180 { "orig":{"tn":"12155551212"}, 181 "dest":{"tn":"12155551214"}, 182 "iat":1443208345, 183 "div":{"tn":"121555551213"} } 185 After the PASSporT header and claims have been constructed, their 186 signature is generated per the guidance in [I-D.ietf-stir-passport] - 187 except for the credential required to sign it. While in the ordinary 188 construction of a PASSporT, the credential used to sign will have 189 authority over the identity in the "orig" claim (for example, a 190 certificate with authority over the telephone number in "orig" per 191 [I-D.ietf-stir-certificates]), for all PASSporTs using the "div" type 192 the signature MUST be created with a credential with authority over 193 the identity present in the "div" claim. So for the example above, 194 where the original "dest" is "12155551213", the signer of the new 195 PASSporT object MUST have authority over that telephone number, and 196 need not have any authority over the telephone number present in the 197 "orig" claim. 199 4. Using 'div' in SIP 201 This section specifies SIP-specific usage for the "div" PASSporT type 202 and its handling in the SIP Identity header field "ppt" parameter 203 value. Other using protocols of PASSporT may define behvaior 204 specific to their use of the "div" claim. 206 4.1. Authentication Service Behavior 208 An authentication service only adds an Identity header field 209 containing the "div" PASSporT type to an SIP request that already 210 contains at least one Identity header field; it MUST NOT add a "div" 211 request to an INVITE that contains no other Identity headers fields. 212 Note that the authentication service doing so does not remove or 213 replace any existing Identity header fields, it simply adds a new 214 one. When adding an Identity header field with a PASSporT object 215 containing a "div" claim, SIP authentication services MUST also add a 216 "ppt" parameter to that Identity header with a value of "div". The 217 resulting compact form Identity header field to add to the message 218 might look as follows: 220 Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 221 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 222 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 223 info=;alg=ES256;ppt="div" 225 A SIP authentication service typically will derive the new value of 226 "dest" from a new Request-URI that is set for the SIP request before 227 it is forwarded. Older values of the Request-URI may appear in 228 header fields like Diversion or History-Info; this document specifies 229 no specific interaction between the "div" mechanism and those SIP 230 header fields. Note as well that because PASSporT operates on 231 canonicalized telephone numbers and normalized URIs, many smaller 232 changes to the syntax of identifiers that might be captured by other 233 mechanisms (like History-Info) that record regargeting will likely 234 not require a "div" PASSporT. 236 4.2. Verification Service Behavior 238 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 239 specifications defining "ppt" values describe any additional verifier 240 behavior. The behavior specified for the "div" value of "ppt" is as 241 follows. 243 In order to use the "div" extension, a verificiation service needs to 244 inspect all of the valid Identity header field values associated with 245 a request, as an Identity header field value containing "div" 246 necessary refers to an earlier PASSporT already in the message. In 247 particular, the verification service must find a PASSporT associated 248 with the call, one created earlier, that contains a "dest" claim with 249 a value equivalent to the "div" claim in the current PASSporT. It is 250 possible that this earlier PASSporT will also contain a "div", and 251 that it will in turn chain to a still earlier PASSporT stored in a 252 different Identity header field value. Ultimately, by looking at 253 this chain of transformations and validating the associated 254 signatures, the verification service will be able to ascertain that 255 the appropriate parties were responsible for the retargeting of the 256 call to its ultimate destination; this can help the verification 257 service to determine that original PASSporT in the call was not 258 simply used in a cut-and-paste attack. This will help relying 259 parties to make any associated authorization decisions in terms of 260 how the call will be treated - though, per [I-D.ietf-stir-rfc4474bis] 261 Section 6.2.1, that decision is a matter of local policy. 263 Note that Identity header fields are not ordered in a SIP request, 264 and in a case where there is a multiplicity of Identity header fields 265 in a request, some sorting may be required to match divert PASSporTs 266 to their originals. 268 5. Using 'div' in STIR out-of-band 270 When storing a PASSporT with "div" at a Call Placement Service (CPS) 271 for STIR out-of-band [I-D.ietf-stir-rfc4474bis] scenarios, clients 272 should include an "opt" element within "div". "opt" contains the full 273 form of the original PASSporT from which the "div" was generated. If 274 the diverting entity originally received that PASSporT encrypted, it 275 MUST decrypt it before storing it in "opt." The entire "div" 276 PASSporT would than be signed and re-encrypted normally for storage 277 at an out-of-band Call Placement Service (CPS). 279 A "div" PASSporT containing the "opt" would look as follows: 281 { "orig":{"tn":"12155551212"}, 282 "dest":{"tn":"12155551214"}, 283 "iat":1443208345, 284 "div":{"tn":"121555551213", 285 "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ 286 joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ 287 kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ 288 I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ 289 q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ 290 ojNCpTzO3QfPOlckGaS6hEck7w"} } 292 The "opt" extension is not required for any unencrypted in-band 293 PASSporT conveyance. For forward compatibility reasons, its use is 294 not forbidden in those environments. 296 6. Extending 'div' 298 Past experience has shown that there may be additional information 299 about the motivation for retargeting that relying parties might 300 consider when making authorization decisions about a call, see for 301 example the "reason" associated with the SIP Diversion header field 302 [RFC5806]. Future extensions to this specification might incorporate 303 reasons into "div". 305 7. Acknowledgments 307 We would like to thank Robert Sparks for contributions to this 308 document. 310 8. IANA Considerations 312 This specification requests that the IANA add a new claim to the JSON 313 Web Token Claims registry as defined in [RFC7519]. 315 Claim Name: "div" 317 Claim Description: New Target of a Call 319 Change Controller: IESG 321 Specification Document(s): [RFCThis] 323 9. Security Considerations 325 This specification describes a security feature, and is primarily 326 concerned with increasing security when calls are forwarded. 327 Including information about how calls were retargeted during the 328 routing process can allow downstream entities to infer particulars of 329 the policies used to route calls through the network. However, 330 including this information about forwarding is at the discretion of 331 the retargeting entity, so if there is a requirement to keep the 332 original called number confidential, no PASSporT should be created 333 for that retargeting - the only consequence will be that downstream 334 entities will be unable to correlate an incoming call with the 335 original PASSporT without access to some prior knowledge of the 336 policies that could have caused the retargeting. 338 10. Informative References 340 [I-D.ietf-stir-certificates] 341 Peterson, J. and S. Turner, "Secure Telephone Identity 342 Credentials: Certificates", draft-ietf-stir- 343 certificates-14 (work in progress), May 2017. 345 [I-D.ietf-stir-oob] 346 Rescorla, E. and J. Peterson, "STIR Out of Band 347 Architecture and Use Cases", draft-ietf-stir-oob-00 (work 348 in progress), July 2017. 350 [I-D.ietf-stir-passport] 351 Wendt, C. and J. Peterson, "Personal Assertion Token 352 (PASSporT)", draft-ietf-stir-passport-11 (work in 353 progress), February 2017. 355 [I-D.ietf-stir-rfc4474bis] 356 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 357 "Authenticated Identity Management in the Session 358 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 359 (work in progress), February 2017. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 367 A., Peterson, J., Sparks, R., Handley, M., and E. 368 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 369 DOI 10.17487/RFC3261, June 2002, 370 . 372 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 373 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 374 . 376 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 377 C. Holmberg, "An Extension to the Session Initiation 378 Protocol (SIP) for Request History Information", RFC 7044, 379 DOI 10.17487/RFC7044, February 2014, 380 . 382 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 383 Telephone Identity Problem Statement and Requirements", 384 RFC 7340, DOI 10.17487/RFC7340, September 2014, 385 . 387 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 388 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 389 . 391 Author's Address 393 Jon Peterson 394 Neustar, Inc. 395 1800 Sutter St Suite 570 396 Concord, CA 94520 397 US 399 Email: jon.peterson@neustar.biz