Network Working Group J. Peterson Internet-Draft Neustar Intended status: Informational October 31, 2016 Expires: May 4, 2017 PASSporT Extension for Diverted Calls draft-peterson-passport-divert-00.txt Abstract This document extends PASSporT, which conveys cryptographically- signed information about the people involved in personal communications, to include an indication that a call has been diverted from its originally destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Peterson Expires May 4, 2017 [Page 1] Internet-Draft STIR Caller Name October 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. PASSporT 'div' Claim . . . . . . . . . . . . . . . . . . . . 3 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 5 4.1. Authentication Service Behavior . . . . . . . . . . . . . 5 4.2. Verification Service Behavior . . . . . . . . . . . . . . 5 5. Extending 'div' . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the people involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to include an indication that a call has been diverted from its originally destination to a new one. Although the STIR problem statement [RFC7340] is focused on preventing the impersonation of the caller's identity, which is a common enabler for threats such as robocalling and voicemail hacking on the telephone network today, it also provides a signature over the called number as the authentication service sees it. As [I-D.ietf-stir-rfc4474bis] Section 12.1 describes, this protection over the contents of the To header field is intended to prevent a class of cut-and-paste attacks. If Alice calls Bob, for example, Bob might attempt to cut-and-paste the Identity header in Alice's INVITE into a new INVITE that Bob sends to Carol, and thus be able to fool Carol into thinking the call came from Alice and not Bob. With the signature over the To header, the INVITE Carol sees will clearly have been destined originally for Bob, and thus Carol can view the INVITE as suspect. However, as [I-D.ietf-stir-rfc4474bis] Section 12.1.1 points out, it is difficult for Carol to confirm or reject these suspicions based on the information she receives from the baseline PASSporT object. Peterson Expires May 4, 2017 [Page 2] Internet-Draft STIR Caller Name October 2016 The common "call forwarding" service serves as a good example of the fact that the original called party number is not always the numebr to which the call is delivered. While the address in the To header field value of SIP requests is not supposed to change accordingly to baseline [RFC3261], as it is the Request-URI that is supposed to be updated as a call is retargeted, practically speaking some operational environments do alter the To header field. There are a number of potential ways for intermediaries to indicate that such a forwarding operating has taken place. The History-Info header field [RFC7044] was created to store the Request-URIs that are discarded by a call in transit. The SIP Diversion header field [RFC5806], though historic, is still used for this purpose by operators today. Neither of these header fields provide any cryptographic assurance of secure redirection, however. This specification therefore extends PASSporT with an explicit indication that original called number in PASSporT no longer reflects the destination to which a call is likely to be delivered. Verification services and the relying parties who make authorization decisions about communications may use this indication to confirm that a legitimate retargeting of the call has taken place, rather than a cut-and-paste attack. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. 3. PASSporT 'div' Claim This specification defines a new JSON Web Token claim for "div", which indicates the original destination for a call during its initial routing process. "div" claims are used only in PASSporTs that are based on an existing PASSporT received by a retargeting entity. That retargeting entity will act as an authentication service, creating its own PASSporT header. This MUST include the "div" PASSporT type, and an "x5u" field points to a credential that the retargeting entity controls. This will look as follows: { "typ":"passport", "ppt":"div", "alg":"ES256", "x5u":"https://www.example.com/cert.pkx" } The PASSporT claims object will be populated with a modification of the original token before the call was retargeted: at a high level, Peterson Expires May 4, 2017 [Page 3] Internet-Draft STIR Caller Name October 2016 the original identifier for the called party will move from the "dest" array to the "div" claim. If the "dest" array of the original PASSporT contains multiple identifiers, the retargeting entity MUST select only one them to occupy the "div" field in the new PASSporT: in particular one identifier that is within the scope of the credential that the retargeting entity specified in the "x5u" of the header. The identifier for the new target of the call, as set by the retargeting entity, will replace the contents of the "dest" array of the new PASSporT. The regargeting entity SHOULD retain the "iat" value from the original PASSporT, though in practice many retargeting entities may alter the timestamps in using protocols. All PASSporTS that use the "div" type MUST contain the "div" claim with its corresponding value, which is the value to which the call has been retargeted. No other extension claims should be copied from the original PASSporT to the "div" PASSporT. So, for an original PASSporT of the form: { "orig":{"tn":"12155551212"}, "dest":{"tn":"12155551213"}, "iat":1443208345 } If the retargeting entity is changing the target from 12155551213 to 12155551214, the new PASSporT with "div" would look as follows: { "orig":{"tn":"12155551212"}, "dest":{"tn":"12155551214"}, "iat":1443208345, "div":{"tn":"121555551213"} } After the PASSporT header and claims have been constructed, their signature is generated per the guidance in [I-D.ietf-stir-passport] - except for the credential required to sign it. While in the ordinary construction of a PASSporT, the credential used to sign will have authority over the identity in the "orig" claim (for example, a certificate with authority over the telephone number in "orig" per [I-D.ietf-stir-certificates]), for all PASSporTs using the "div" type the signature MUST be created with a credential with authority over the identity present in the "div" claim. So for the example above, where the original "dest" is "12155551213", the signer of the PASSporT object MUST have authority over that telephone number, and need not have any authority over the telephone number present in the "orig" claim. Peterson Expires May 4, 2017 [Page 4] Internet-Draft STIR Caller Name October 2016 4. Using 'div' in SIP This section specifies SIP-specific usage for the "div" PASSporT type and its handling in the SIP Identity header field "ppt" parameter value. Other using protocols of PASSporT may define behvaior specific to their use of the "div" claim. 4.1. Authentication Service Behavior An authentication service only adds an Identity header field containing the "div" PASSporT type to an SIP request that already contains at least one Identity header field; it MUST NOT add a "div" request to an INVITE that contains no other Identity headers fields. The Identity header When a PASSporT object containing a "div" claim appears in an Identity header, SIP authentication services MUST add a "ppt" parameter to that Identity header with a value of "div". The resulting compact form Identity header might look as follows: Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \ info=;alg=RS256;ppt="div" A SIP authentication service typically will derive the new value of "dest" from a new Request-URI that is added to the SIP request before it is forwarded. Older values of the Request-URI may appear in headers like Diversion or History-Info; this document specifies no specific interaction between the "div" mechanism and those SIP headers. Note as well that because PASSporT operates on canonicalized telephone numbers and normalized URIs, many smaller changes to the syntax of identifiers that might be captured by other mechanisms that record regargeting will likely not require a "div" PASSporT. 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "div" value of "ppt" is as follows. In order to use the "div" extension, a verificiation service needs to inspect all of the valid Identity headers associated with a request, as an Identity header containing "div" necessary refers to an earlier PASSporT associated with the request. In particular, the verification service must find an earlier PASSporT associated with the call that contains a "dest" claim with a value equivalent to the "div" claim in the current PASSporT. It is possible that this Peterson Expires May 4, 2017 [Page 5] Internet-Draft STIR Caller Name October 2016 earlier PASSporT will also contain a "div", and that it will in turn chain to a still earlier PASSporT stored in a different Identity header. Ultimately, by looking at this chain of transformations and validating the associated signatures, the verification service will be able to ascertain that the appropriate parties were responsible for the retargeting of the call to its ultimate destination; this can help the verification service to determine that original PASSporT in the call was not simply used in a cut-and-paste attack. This will in turn help to make any associated authorization decisions in terms of how the call will be treated - though those policies are outside the scope of this document. 5. Extending 'div' Past experience has shown that there may be additional information about the motyvation for retargeting that relying parties might consider when making authorization decisions about a call. Future versions of this specification will explore ways that that information could be made available in PASSporT. 6. Acknowledgments We would like to thank YOU for contributions to this problem statement and framework. 7. IANA Considerations This specification requests that the IANA add a new claim to the JSON Web Token Claims registry as defined in [RFC7519]. Claim Name: "div" Claim Description: New Target of a Call Change Controller: IESG Specification Document(s): [RFCThis] 8. Security Considerations TBD. 9. Informative References [I-D.ietf-stir-certificates] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", draft-ietf-stir- certificates-10 (work in progress), October 2016. Peterson Expires May 4, 2017 [Page 6] Internet-Draft STIR Caller Name October 2016 [I-D.ietf-stir-passport] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT)", draft-ietf-stir-passport-10 (work in progress), October 2016. [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, . [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . Author's Address Peterson Expires May 4, 2017 [Page 7] Internet-Draft STIR Caller Name October 2016 Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz Peterson Expires May 4, 2017 [Page 8]