idnits 2.17.1 draft-ietf-stir-passport-divert-00.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 (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 292, 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 July 3, 2017 5 Expires: January 4, 2018 7 PASSporT Extension for Diverted Calls 8 draft-ietf-stir-passport-divert-00.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 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 January 4, 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 (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 . . . . . . . . . . . . . . 6 59 5. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 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 field in Alice's 86 INVITE into a new INVITE that Bob sends to Carol, and thus be able to 87 fool Carol into thinking the call came from Alice and not Bob. With 88 the signature over the To header field value, the INVITE Carol sees 89 will clearly have been destined originally for Bob, and thus Carol 90 can view the INVITE 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 number 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 PASSporT header 157 (as 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 instead reflect that date and time. 167 No other extension claims should be copied from the original PASSporT 168 to the "div" 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 Note that the authentication service doing so does not remove or 212 replace any existing Identity header fields, it simply adds a new 213 one. When adding an Identity header field with a PASSporT object 214 containing a "div" claim, SIP authentication services MUST also add a 215 "ppt" parameter to that Identity header with a value of "div". The 216 resulting compact form Identity header field to add to the message 217 might look as follows: 219 Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 220 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 221 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 222 info=;alg=ES256;ppt="div" 224 A SIP authentication service typically will derive the new value of 225 "dest" from a new Request-URI that is set for the SIP request before 226 it is forwarded. Older values of the Request-URI may appear in 227 header fields like Diversion or History-Info; this document specifies 228 no specific interaction between the "div" mechanism and those SIP 229 header fields. Note as well that because PASSporT operates on 230 canonicalized telephone numbers and normalized URIs, many smaller 231 changes to the syntax of identifiers that might be captured by other 232 mechanisms (like History-Info) that record regargeting will likely 233 not require a "div" PASSporT. 235 4.2. Verification Service Behavior 237 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 238 specifications defining "ppt" values describe any additional verifier 239 behavior. The behavior specified for the "div" value of "ppt" is as 240 follows. 242 In order to use the "div" extension, a verificiation service needs to 243 inspect all of the valid Identity header field values associated with 244 a request, as an Identity header field value containing "div" 245 necessary refers to an earlier PASSporT already in the message. In 246 particular, the verification service must find a PASSporT associated 247 with the call, one created earlier, that contains a "dest" claim with 248 a value equivalent to the "div" claim in the current PASSporT. It is 249 possible that this earlier PASSporT will also contain a "div", and 250 that it will in turn chain to a still earlier PASSporT stored in a 251 different Identity header field value. Ultimately, by looking at 252 this chain of transformations and validating the associated 253 signatures, the verification service will be able to ascertain that 254 the appropriate parties were responsible for the retargeting of the 255 call to its ultimate destination; this can help the verification 256 service to determine that original PASSporT in the call was not 257 simply used in a cut-and-paste attack. This will help relying 258 parties to make any associated authorization decisions in terms of 259 how the call will be treated - though, per [I-D.ietf-stir-rfc4474bis] 260 Section 6.2.1, that decision is a matter of local policy. 262 Note that Identity header fields are not ordered in a SIP request, 263 and in a case where there is a multiplicity of Identity header fields 264 in a request, some sorting may be required to match divert PASSporTs 265 to their originals. 267 5. Extending 'div' 269 Past experience has shown that there may be additional information 270 about the motivation for retargeting that relying parties might 271 consider when making authorization decisions about a call, see for 272 example the "reason" associated with the SIP Diversion header field 273 [RFC5806]. Future extensions to this specification might incorporate 274 reasons into "div". 276 6. Acknowledgments 278 We would like to thank Robert Sparks for contributions to this 279 document. 281 7. IANA Considerations 283 This specification requests that the IANA add a new claim to the JSON 284 Web Token Claims registry as defined in [RFC7519]. 286 Claim Name: "div" 288 Claim Description: New Target of a Call 290 Change Controller: IESG 292 Specification Document(s): [RFCThis] 294 8. Security Considerations 296 This specification describes a security feature, and is primarily 297 concerned with increasing security when calls are forwarded. 298 Including information about how calls were retargeted during the 299 routing process can allow downstream entities to infer particulars of 300 the policies used to route calls through the network. However, 301 including this information about forwarding is at the discretion of 302 the retargeting entity, so if there is a requirement to keep the 303 original called number confidential, no PASSporT should be created 304 for that retargeting - the only consequence will be that downstream 305 entities will be unable to correlate an incoming call with the 306 original PASSporT without access to some prior knowledge of the 307 policies that could have caused the retargeting. 309 9. Informative References 311 [I-D.ietf-stir-certificates] 312 Peterson, J. and S. Turner, "Secure Telephone Identity 313 Credentials: Certificates", draft-ietf-stir- 314 certificates-14 (work in progress), May 2017. 316 [I-D.ietf-stir-passport] 317 Wendt, C. and J. Peterson, "Personal Assertion Token 318 (PASSporT)", draft-ietf-stir-passport-11 (work in 319 progress), February 2017. 321 [I-D.ietf-stir-rfc4474bis] 322 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 323 "Authenticated Identity Management in the Session 324 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 325 (work in progress), February 2017. 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, 329 DOI 10.17487/RFC2119, March 1997, 330 . 332 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 333 A., Peterson, J., Sparks, R., Handley, M., and E. 334 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 335 DOI 10.17487/RFC3261, June 2002, 336 . 338 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 339 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 340 . 342 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 343 C. Holmberg, "An Extension to the Session Initiation 344 Protocol (SIP) for Request History Information", RFC 7044, 345 DOI 10.17487/RFC7044, February 2014, 346 . 348 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 349 Telephone Identity Problem Statement and Requirements", 350 RFC 7340, DOI 10.17487/RFC7340, September 2014, 351 . 353 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 354 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 355 . 357 Author's Address 359 Jon Peterson 360 Neustar, Inc. 361 1800 Sutter St Suite 570 362 Concord, CA 94520 363 US 365 Email: jon.peterson@neustar.biz