idnits 2.17.1 draft-peterson-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 (October 31, 2016) is 2731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCThis' is mentioned on line 271, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-10 == Outdated reference: A later version (-11) exists of draft-ietf-stir-passport-10 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-14 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 31, 2016 5 Expires: May 4, 2017 7 PASSporT Extension for Diverted Calls 8 draft-peterson-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 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 May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 6 63 9. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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. However, as [I-D.ietf-stir-rfc4474bis] Section 12.1.1 91 points out, it is difficult for Carol to confirm or reject these 92 suspicions based on the information she receives from the baseline 93 PASSporT object. 95 The common "call forwarding" service serves as a good example of the 96 fact that the original called party number is not always the numebr 97 to which the call is delivered. While the address in the To header 98 field value of SIP requests is not supposed to change accordingly to 99 baseline [RFC3261], as it is the Request-URI that is supposed to be 100 updated as a call is retargeted, practically speaking some 101 operational environments do alter the To header field. There are a 102 number of potential ways for intermediaries to indicate that such a 103 forwarding operating has taken place. The History-Info header field 104 [RFC7044] was created to store the Request-URIs that are discarded by 105 a call in transit. The SIP Diversion header field [RFC5806], though 106 historic, is still used for this purpose by operators today. Neither 107 of these header fields provide any cryptographic assurance of secure 108 redirection, however. 110 This specification therefore extends PASSporT with an explicit 111 indication that original called number in PASSporT no longer reflects 112 the destination to which a call is likely to be delivered. 113 Verification services and the relying parties who make authorization 114 decisions about communications may use this indication to confirm 115 that a legitimate retargeting of the call has taken place, rather 116 than a cut-and-paste attack. 118 2. Terminology 120 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 121 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 122 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 123 described in RFC 2119 [RFC2119]. 125 3. PASSporT 'div' Claim 127 This specification defines a new JSON Web Token claim for "div", 128 which indicates the original destination for a call during its 129 initial routing process. "div" claims are used only in PASSporTs that 130 are based on an existing PASSporT received by a retargeting entity. 131 That retargeting entity will act as an authentication service, 132 creating its own PASSporT header. This MUST include the "div" 133 PASSporT type, and an "x5u" field points to a credential that the 134 retargeting entity controls. This will look as follows: 136 { "typ":"passport", 137 "ppt":"div", 138 "alg":"ES256", 139 "x5u":"https://www.example.com/cert.pkx" } 141 The PASSporT claims object will be populated with a modification of 142 the original token before the call was retargeted: at a high level, 143 the original identifier for the called party will move from the 144 "dest" array to the "div" claim. If the "dest" array of the original 145 PASSporT contains multiple identifiers, the retargeting entity MUST 146 select only one them to occupy the "div" field in the new PASSporT: 147 in particular one identifier that is within the scope of the 148 credential that the retargeting entity specified in the "x5u" of the 149 header. The identifier for the new target of the call, as set by the 150 retargeting entity, will replace the contents of the "dest" array of 151 the new PASSporT. The regargeting entity SHOULD retain the "iat" 152 value from the original PASSporT, though in practice many retargeting 153 entities may alter the timestamps in using protocols. All PASSporTS 154 that use the "div" type MUST contain the "div" claim with its 155 corresponding value, which is the value to which the call has been 156 retargeted. No other extension claims should be copied from the 157 original PASSporT to the "div" PASSporT. 159 So, for an original PASSporT of the form: 161 { "orig":{"tn":"12155551212"}, 162 "dest":{"tn":"12155551213"}, 163 "iat":1443208345 } 165 If the retargeting entity is changing the target from 12155551213 to 166 12155551214, the new PASSporT with "div" would look as follows: 168 { "orig":{"tn":"12155551212"}, 169 "dest":{"tn":"12155551214"}, 170 "iat":1443208345, 171 "div":{"tn":"121555551213"} } 173 After the PASSporT header and claims have been constructed, their 174 signature is generated per the guidance in [I-D.ietf-stir-passport] - 175 except for the credential required to sign it. While in the ordinary 176 construction of a PASSporT, the credential used to sign will have 177 authority over the identity in the "orig" claim (for example, a 178 certificate with authority over the telephone number in "orig" per 179 [I-D.ietf-stir-certificates]), for all PASSporTs using the "div" type 180 the signature MUST be created with a credential with authority over 181 the identity present in the "div" claim. So for the example above, 182 where the original "dest" is "12155551213", the signer of the 183 PASSporT object MUST have authority over that telephone number, and 184 need not have any authority over the telephone number present in the 185 "orig" claim. 187 4. Using 'div' in SIP 189 This section specifies SIP-specific usage for the "div" PASSporT type 190 and its handling in the SIP Identity header field "ppt" parameter 191 value. Other using protocols of PASSporT may define behvaior 192 specific to their use of the "div" claim. 194 4.1. Authentication Service Behavior 196 An authentication service only adds an Identity header field 197 containing the "div" PASSporT type to an SIP request that already 198 contains at least one Identity header field; it MUST NOT add a "div" 199 request to an INVITE that contains no other Identity headers fields. 200 The Identity header When a PASSporT object containing a "div" claim 201 appears in an Identity header, SIP authentication services MUST add a 202 "ppt" parameter to that Identity header with a value of "div". The 203 resulting compact form Identity header might look as follows: 205 Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo 206 eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp 207 pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ 208 info=;alg=RS256;ppt="div" 210 A SIP authentication service typically will derive the new value of 211 "dest" from a new Request-URI that is added to the SIP request before 212 it is forwarded. Older values of the Request-URI may appear in 213 headers like Diversion or History-Info; this document specifies no 214 specific interaction between the "div" mechanism and those SIP 215 headers. Note as well that because PASSporT operates on 216 canonicalized telephone numbers and normalized URIs, many smaller 217 changes to the syntax of identifiers that might be captured by other 218 mechanisms that record regargeting will likely not require a "div" 219 PASSporT. 221 4.2. Verification Service Behavior 223 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that 224 specifications defining "ppt" values describe any additional verifier 225 behavior. The behavior specified for the "div" value of "ppt" is as 226 follows. 228 In order to use the "div" extension, a verificiation service needs to 229 inspect all of the valid Identity headers associated with a request, 230 as an Identity header containing "div" necessary refers to an earlier 231 PASSporT associated with the request. In particular, the 232 verification service must find an earlier PASSporT associated with 233 the call that contains a "dest" claim with a value equivalent to the 234 "div" claim in the current PASSporT. It is possible that this 235 earlier PASSporT will also contain a "div", and that it will in turn 236 chain to a still earlier PASSporT stored in a different Identity 237 header. Ultimately, by looking at this chain of transformations and 238 validating the associated signatures, the verification service will 239 be able to ascertain that the appropriate parties were responsible 240 for the retargeting of the call to its ultimate destination; this can 241 help the verification service to determine that original PASSporT in 242 the call was not simply used in a cut-and-paste attack. This will in 243 turn help to make any associated authorization decisions in terms of 244 how the call will be treated - though those policies are outside the 245 scope of this document. 247 5. Extending 'div' 249 Past experience has shown that there may be additional information 250 about the motyvation for retargeting that relying parties might 251 consider when making authorization decisions about a call. Future 252 versions of this specification will explore ways that that 253 information could be made available in PASSporT. 255 6. Acknowledgments 257 We would like to thank YOU for contributions to this problem 258 statement and framework. 260 7. IANA Considerations 262 This specification requests that the IANA add a new claim to the JSON 263 Web Token Claims registry as defined in [RFC7519]. 265 Claim Name: "div" 267 Claim Description: New Target of a Call 269 Change Controller: IESG 271 Specification Document(s): [RFCThis] 273 8. Security Considerations 275 TBD. 277 9. Informative References 279 [I-D.ietf-stir-certificates] 280 Peterson, J. and S. Turner, "Secure Telephone Identity 281 Credentials: Certificates", draft-ietf-stir- 282 certificates-10 (work in progress), October 2016. 284 [I-D.ietf-stir-passport] 285 Wendt, C. and J. Peterson, "Personal Assertion Token 286 (PASSporT)", draft-ietf-stir-passport-10 (work in 287 progress), October 2016. 289 [I-D.ietf-stir-rfc4474bis] 290 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 291 "Authenticated Identity Management in the Session 292 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14 293 (work in progress), October 2016. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, 297 DOI 10.17487/RFC2119, March 1997, 298 . 300 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 301 A., Peterson, J., Sparks, R., Handley, M., and E. 302 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 303 DOI 10.17487/RFC3261, June 2002, 304 . 306 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 307 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 308 . 310 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 311 C. Holmberg, "An Extension to the Session Initiation 312 Protocol (SIP) for Request History Information", RFC 7044, 313 DOI 10.17487/RFC7044, February 2014, 314 . 316 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 317 Telephone Identity Problem Statement and Requirements", 318 RFC 7340, DOI 10.17487/RFC7340, September 2014, 319 . 321 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 322 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 323 . 325 Author's Address 326 Jon Peterson 327 Neustar, Inc. 328 1800 Sutter St Suite 570 329 Concord, CA 94520 330 US 332 Email: jon.peterson@neustar.biz