idnits 2.17.1 draft-peterson-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 are 2 instances 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 (June 12, 2017) is 2510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 283, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 Summary: 1 error (**), 0 flaws (~~), 4 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 June 12, 2017 5 Expires: December 14, 2017 7 PASSporT Extension for Diverted Calls 8 draft-peterson-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 originally 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 http://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 December 14, 2017. 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 (http://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 . . . . . . . . . . . . . . 5 59 5. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 9. Informative References . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 PASSporT [I-D.ietf-stir-passport] is a token format based on JWT 69 [RFC7519] for conveying cryptographically-signed information about 70 the people involved in personal communications; it is used with STIR 71 [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the 72 identity of the participants in real-time communications established 73 via a protocol like SIP. This specification extends PASSporT to 74 include an indication that a call has been diverted from its 75 originally destination to a new one. 77 Although the STIR problem statement [RFC7340] is focused on 78 preventing the impersonation of the caller's identity, which is a 79 common enabler for threats such as robocalling and voicemail hacking 80 on the telephone network today, it also provides a signature over the 81 called number as the authentication service sees it. As 82 [I-D.ietf-stir-rfc4474bis] Section 12.1 describes, this protection 83 over the contents of the To header field is intended to prevent a 84 class of cut-and-paste attacks. If Alice calls Bob, for example, Bob 85 might attempt to cut-and-paste the Identity header in Alice's INVITE 86 into a new INVITE that Bob sends to Carol, and thus be able to fool 87 Carol into thinking the call came from Alice and not Bob. With the 88 signature over the To header, the INVITE Carol sees will clearly have 89 been destined originally for Bob, and thus Carol can view the INVITE 90 as suspect. 92 However, as [I-D.ietf-stir-rfc4474bis] Section 12.1.1 points out, it 93 is difficult for Carol to confirm or reject these suspicions based on 94 the information she receives from the baseline PASSporT object. The 95 common "call forwarding" service serves as a good example of the fact 96 that the original called party number is not always the numebr to 97 which a call is delivered. The address in the To header field value 98 of SIP requests is not supposed to change, accordingly to baseline 99 [RFC3261], as it is the Request-URI that is supposed to be updated 100 when a call is retargeted, but practically speaking some operational 101 environments do alter the To header field. There are a number of 102 potential ways for intermediaries to indicate that such a forwarding 103 operating has taken place. The History-Info header field [RFC7044] 104 was created to store the Request-URIs that are discarded by a call in 105 transit. The SIP Diversion header field [RFC5806], though historic, 106 is still used for this purpose by some operators today. Neither of 107 these header fields provide any cryptographic assurance of secure 108 redirection, and they can both capture minor syntactical changes in 109 URIs that do not reflect a change to the actual target of a call. 111 This specification therefore extends PASSporT with an explicit 112 indication that original called number in PASSporT no longer reflects 113 the destination to which a call is likely to be delivered. 114 Verification services and the relying parties who make authorization 115 decisions about communications may use this indication to confirm 116 that a legitimate retargeting of the call has taken place, rather 117 than a cut-and-paste attack. 119 2. Terminology 121 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 123 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 124 described in [RFC2119]. 126 3. PASSporT 'div' Claim 128 This specification defines a new JSON Web Token claim for "div" which 129 indicates a previous destination for a call during its routing 130 process. When a retargeting entity receives a call signed with a 131 PASSporT, it may act as an authentication service and create a new 132 PASSporT containing the "div" claim to attach to the call (without 133 removing the original PASSporT). Note that a new PASSporT is only 134 necessary when the cannical form of the "dest" identifier (per the 135 canonicalization procedures in [I-D.ietf-stir-rfc4474bis] Section 8) 136 changes due to this retargeting. "div" is typically populated with a 137 destination address found in the "dest" field of PASSporT received by 138 the retargeting entity. These new PASSporT generated by retargeting 139 entities MUST include the "div" PASSporT type, and an "x5u" field 140 pointing to a credential that the retargeting entity controls. The 141 new PASSporT will look as follows: 143 { "typ":"passport", 144 "ppt":"div", 145 "alg":"ES256", 146 "x5u":"https://www.example.com/cert.pkx" } 148 A PASSporT claims object containing "div" is populated with a 149 modification of the original token before the call was retargeted: at 150 a high level, the original identifier for the called party in the 151 "dest" array will become the "div" claim in the new PASSporT. If the 152 "dest" array of the original PASSporT contains multiple identifiers, 153 the retargeting entity MUST select only one them to occupy the "div" 154 field in the new PASSporT. and in particular, it MUST select an 155 identifier that is within the scope of the credential that the 156 retargeting entity will specify in the "x5u" of the header (as 157 described below). 159 The new target for the call selected by the retargeting entity 160 becomes the value of the "dest" array of the new PASSporT. The 161 "orig" value MUST be copied into the new PASSporT from the original 162 PASSporT received by the retargeting entity; the regargeting entity 163 SHOULD retain the "iat" value from the original PASSporT, though if 164 in the underlying signaling protocol (e.g. SIP) the retargeting 165 entity changes the date and time information in the retargeted 166 request, the new PASSporT should reflect that. No other extension 167 claims should be copied from the original PASSporT to the "div" 168 PASSporT. 170 So, for an original PASSporT of the form: 172 { "orig":{"tn":"12155551212"}, 173 "dest":{"tn":"12155551213"}, 174 "iat":1443208345 } 176 If the retargeting entity is changing the target from 12155551213 to 177 12155551214, the new PASSporT with "div" would look as follows: 179 { "orig":{"tn":"12155551212"}, 180 "dest":{"tn":"12155551214"}, 181 "iat":1443208345, 182 "div":{"tn":"121555551213"} } 184 After the PASSporT header and claims have been constructed, their 185 signature is generated per the guidance in [I-D.ietf-stir-passport] - 186 except for the credential required to sign it. While in the ordinary 187 construction of a PASSporT, the credential used to sign will have 188 authority over the identity in the "orig" claim (for example, a 189 certificate with authority over the telephone number in "orig" per 190 [I-D.ietf-stir-certificates]), for all PASSporTs using the "div" type 191 the signature MUST be created with a credential with authority over 192 the identity present in the "div" claim. So for the example above, 193 where the original "dest" is "12155551213", the signer of the new 194 PASSporT object MUST have authority over that telephone number, and 195 need not have any authority over the telephone number present in the 196 "orig" claim. 198 4. Using 'div' in SIP 200 This section specifies SIP-specific usage for the "div" PASSporT type 201 and its handling in the SIP Identity header field "ppt" parameter 202 value. Other using protocols of PASSporT may define behvaior 203 specific to their use of the "div" claim. 205 4.1. Authentication Service Behavior 207 An authentication service only adds an Identity header field 208 containing the "div" PASSporT type to an SIP request that already 209 contains at least one Identity header field; it MUST NOT add a "div" 210 request to an INVITE that contains no other Identity headers fields. 211 When adding an Identity header with a PASSporT object containing a 212 "div" claim, SIP authentication services MUST also add a "ppt" 213 parameter to that Identity header with a value of "div". The 214 resulting compact form Identity header might look as follows: 216 Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 217 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 218 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 219 info=;alg=ES256;ppt="div" 221 A SIP authentication service typically will derive the new value of 222 "dest" from a new Request-URI that is set for the SIP request before 223 it is forwarded. Older values of the Request-URI may appear in 224 headers like Diversion or History-Info; this document specifies no 225 specific interaction between the "div" mechanism and those SIP 226 headers. Note as well that because PASSporT operates on 227 canonicalized telephone numbers and normalized URIs, many smaller 228 changes to the syntax of identifiers that might be captured by other 229 mechanisms (like History-Info) that record regargeting will likely 230 not require a "div" PASSporT. 232 4.2. Verification Service Behavior 234 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 235 specifications defining "ppt" values describe any additional verifier 236 behavior. The behavior specified for the "div" value of "ppt" is as 237 follows. 239 In order to use the "div" extension, a verificiation service needs to 240 inspect all of the valid Identity headers associated with a request, 241 as an Identity header containing "div" necessary refers to an earlier 242 PASSporT associated with the request. In particular, the 243 verification service must find an earlier PASSporT associated with 244 the call that contains a "dest" claim with a value equivalent to the 245 "div" claim in the current PASSporT. It is possible that this 246 earlier PASSporT will also contain a "div", and that it will in turn 247 chain to a still earlier PASSporT stored in a different Identity 248 header. Ultimately, by looking at this chain of transformations and 249 validating the associated signatures, the verification service will 250 be able to ascertain that the appropriate parties were responsible 251 for the retargeting of the call to its ultimate destination; this can 252 help the verification service to determine that original PASSporT in 253 the call was not simply used in a cut-and-paste attack. This will 254 help relying parties to make any associated authorization decisions 255 in terms of how the call will be treated - though those policies are 256 outside the scope of this document. 258 5. Extending 'div' 260 Past experience has shown that there may be additional information 261 about the motivation for retargeting that relying parties might 262 consider when making authorization decisions about a call, see for 263 example the "reason" associated with the SIP Diversion header field 264 [RFC5806]. Future extensions to this specification might incorporate 265 reasons into "div". 267 6. Acknowledgments 269 We would like to thank YOU for contributions to this problem 270 statement and framework. 272 7. IANA Considerations 274 This specification requests that the IANA add a new claim to the JSON 275 Web Token Claims registry as defined in [RFC7519]. 277 Claim Name: "div" 279 Claim Description: New Target of a Call 281 Change Controller: IESG 283 Specification Document(s): [RFCThis] 285 8. Security Considerations 287 This specification describes a security feature, and is primarily 288 concerned with increasing security when calls are forwarded. 289 Including information about how calls were retargeted during the 290 routing process can reveal to downstream entities particulars of the 291 policies used to route calls through the network. But including this 292 information about forwarding is at the discretion of the retargeting 293 entity, so if there is a requirement to keep the original called 294 number confidential, no PASSporT should be created for that 295 retargeting - the only consequence will be that downstream entities 296 will have less confidence that the PASSporT was meant to be 297 associated with this call. 299 9. Informative References 301 [I-D.ietf-stir-certificates] 302 Peterson, J. and S. Turner, "Secure Telephone Identity 303 Credentials: Certificates", draft-ietf-stir- 304 certificates-14 (work in progress), May 2017. 306 [I-D.ietf-stir-passport] 307 Wendt, C. and J. Peterson, "Personal Assertion Token 308 (PASSporT)", draft-ietf-stir-passport-11 (work in 309 progress), February 2017. 311 [I-D.ietf-stir-rfc4474bis] 312 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 313 "Authenticated Identity Management in the Session 314 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 315 (work in progress), February 2017. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 323 A., Peterson, J., Sparks, R., Handley, M., and E. 324 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 325 DOI 10.17487/RFC3261, June 2002, 326 . 328 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 329 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 330 . 332 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 333 C. Holmberg, "An Extension to the Session Initiation 334 Protocol (SIP) for Request History Information", RFC 7044, 335 DOI 10.17487/RFC7044, February 2014, 336 . 338 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 339 Telephone Identity Problem Statement and Requirements", 340 RFC 7340, DOI 10.17487/RFC7340, September 2014, 341 . 343 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 344 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 345 . 347 Author's Address 349 Jon Peterson 350 Neustar, Inc. 351 1800 Sutter St Suite 570 352 Concord, CA 94520 353 US 355 Email: jon.peterson@neustar.biz