Network Working Group                                        J. Peterson
Internet-Draft                                                   Neustar
Intended status: Informational                             March 5, 2018
Expires: September 6, 2018

                 PASSporT Extension for Diverted Calls


   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 original 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

   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 September 6, 2018.

Copyright Notice

   Copyright (c) 2018 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
   ( 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 September 6, 2018               [Page 1]

Internet-Draft              PASSporT Diverted                 March 2018

   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
     3.1.  Nesting the original PASSporT in 'div'  . . . . . . . . .   5
   4.  Using 'div' in SIP  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Authentication Service Behavior . . . . . . . . . . . . .   6
     4.2.  Verification Service Behavior . . . . . . . . . . . . . .   6
   5.  'div' and Redirection . . . . . . . . . . . . . . . . . . . .   7
   6.  Extending 'div' to work with Service Logic Tracking . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   PASSporT [RFC8225] 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 [RFC8224]
   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 [RFC8224]
   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 field 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 field value, the INVITE Carol sees will clearly have been
   destined originally for Bob, and thus Carol can view the INVITE as

   However, as [RFC8224] 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.  The common "call

Peterson                Expires September 6, 2018               [Page 2]

Internet-Draft              PASSporT Diverted                 March 2018

   forwarding" service serves as a good example of the fact that the
   original called party number is not always the number to which a call
   is delivered.  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
   when a call is retargeted, but 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 some operators today.  Neither of
   these header fields provide any cryptographic assurance of secure
   redirection, and they can both capture minor syntactical changes in
   URIs that do not reflect a change to the actual target of a call.

   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",
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in [RFC2119].

3.  PASSporT 'div' Claim

   This specification defines a new JSON Web Token claim for "div" which
   indicates a previous destination for a call during its routing
   process.  When a retargeting entity receives a call signed with a
   PASSporT, it may act as an authentication service and create a new
   PASSporT containing the "div" claim to attach to the call (without
   removing the original PASSporT).  Note that a new PASSporT is only
   necessary when the canonical form of the "dest" identifier (per the
   canonicalization procedures in [RFC8224] Section 8) changes due to
   this retargeting. "div" is typically populated with a destination
   address found in the "dest" field of PASSporT received by the
   retargeting entity, though it may include other elements as well,
   including a copy of the original PASSporT.  These new PASSporT
   generated by retargeting entities MUST include the "div" PASSporT
   type, and an "x5u" field pointing to a credential that the

Peterson                Expires September 6, 2018               [Page 3]

Internet-Draft              PASSporT Diverted                 March 2018

   retargeting entity controls.  The new PASSporT header will look as

   { "typ":"passport",
     "x5u":"" }

   A PASSporT claims object containing "div" is populated with a
   modification of the original token before the call was retargeted: at
   a high level, the original identifier for the called party in the
   "dest" array will become the "div" claim in the new PASSporT.  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. and in particular, it MUST select an
   identifier that is within the scope of the credential that the
   retargeting entity will specify in the "x5u" of the PASSporT header
   (as described below).

   The new target for the call selected by the retargeting entity
   becomes the value of the "dest" array of the new PASSporT.  The
   "orig" value MUST be copied into the new PASSporT from the original
   PASSporT received by the retargeting entity.  The retargeting entity
   SHOULD retain the "iat" value from the original PASSporT, though if
   in the underlying signaling protocol (e.g.  SIP) the retargeting
   entity changes the date and time information in the retargeted
   request, the new PASSporT should instead reflect that date and time.
   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"},
        "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"},
        "div":{"tn":"121555551213"} }

   Note that the "div" claim may contain other elements than just a
   destination, including a copy of the original PASSporT (see
   Section 3.1).  After the PASSporT header and claims have been
   constructed, their signature is generated per the guidance in

Peterson                Expires September 6, 2018               [Page 4]

Internet-Draft              PASSporT Diverted                 March 2018

   [RFC8225] - 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 [RFC8226]), 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 new PASSporT
   object MUST have authority over that telephone number, and need not
   have any authority over the telephone number present in the "orig"

3.1.  Nesting the original PASSporT in 'div'

   For some use cases, rather than having multiple unconnected PASSporTS
   associated with a single call, it makes more sense to nest the
   PASSporTs, explicitly relating two PASSporTs to one another.  For
   example, when storing a PASSporT with "div" at a Call Placement
   Service (CPS) for STIR out-of-band [I-D.ietf-stir-oob] scenarios,
   clients MUST include an "opt" element within "div". "opt" contains
   the full form of the original PASSporT from which the "div" was
   generated.  If the diverting entity originally received that PASSporT
   encrypted, it MUST decrypt it before storing it in "opt."  The entire
   "div" PASSporT would than be signed and re-encrypted normally for
   storage at an out-of-band Call Placement Service (CPS).

   A "div" PASSporT containing the "opt" would look as follows:

      { "orig":{"tn":"12155551212"},
        "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
        kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
        I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
        q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
        ojNCpTzO3QfPOlckGaS6hEck7w"} }

   The "opt" extension is RECOMMENDED for use within in-band SIP use
   cases as well.  The alternative, having multiple Identity headers in
   a SIP request, could be confusing for some verification services.
   However, nested PASSporTs could result in lengthy Identity headers,
   and some operational experience is needed to ascertain how viable
   multiple layers of nesting will be.

Peterson                Expires September 6, 2018               [Page 5]

Internet-Draft              PASSporT Diverted                 March 2018

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 behavior
   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.
   Note that the authentication service doing so does not remove or
   replace any existing Identity header fields, it simply adds a new
   one.  When adding an Identity header field with a PASSporT object
   containing a "div" claim, SIP authentication services MUST also add a
   "ppt" parameter to that Identity header with a value of "div".  The
   resulting compact form Identity header field to add to the message
   might look as follows:

  Identity: ..sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
      pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=; \

   A SIP authentication service typically will derive the new value of
   "dest" from a new Request-URI that is set for the SIP request before
   it is forwarded.  Older values of the Request-URI may appear in
   header fields like Diversion or History-Info; this document specifies
   no specific interaction between the "div" mechanism and those SIP
   header fields.  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 (like History-Info) that record retargeting will likely
   not require a "div" PASSporT.

4.2.  Verification Service Behavior

   [RFC8224] 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 verification service needs to
   inspect all of the valid Identity header field values associated with
   a request, as an Identity header field value containing "div"
   necessary refers to an earlier PASSporT already in the message.  In
   particular, the verification service must find a PASSporT associated

Peterson                Expires September 6, 2018               [Page 6]

Internet-Draft              PASSporT Diverted                 March 2018

   with the call, one created earlier, that contains a "dest" claim with
   a value equivalent to the "div" claim in the current PASSporT.  It is
   possible that this 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 field value.  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 help relying
   parties to make any associated authorization decisions in terms of
   how the call will be treated - though, per [RFC8224] Section 6.2.1,
   that decision is a matter of local policy.

   Note that Identity header fields are not ordered in a SIP request,
   and in a case where there is a multiplicity of Identity header fields
   in a request, some sorting may be required to match divert PASSporTs
   to their originals.

5.  'div' and Redirection

   The "div" mechanism exists primarily to prevent false negatives at
   verification services when an arriving SIP request, due to
   intermediary retargeting, does not appear to be intended for its
   eventual recipient, because its "dest" value designates a different
   original destination.  Any intermediary that assigns a new target to
   a request could choose to redirect with a 3xx response code instead
   of retargeting.  In ordinary operations, a redirection poses no
   difficult for the operations of baseline STIR: when the UAC receives
   the 3xx response, it will initiate a new request to the new target
   (typically carried in the Contact header field value of the 3xx), and
   the "dest" of the PASSporT created for the new request will match
   that new target.  As no impersonation attack can arise from this
   case, it creates no new requirement for STIR.

   However, some UACs record the original target of a call with
   mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and
   may want to leverage STIR to demonstrate to the ultimate recipient
   that the call has been redirected securely: that is, that the
   original destination was the one that sent the redirection message
   that led to the recipient receiving the request.  The semantics of
   the PASSporT necessary to attest that are the same as those for the
   "div" retargeting cases above.  The only wrinkle is that the PASSporT
   needs to be generated by the redirecting entity and sent back to the
   originating user agent client within the 3xx response.

Peterson                Expires September 6, 2018               [Page 7]

Internet-Draft              PASSporT Diverted                 March 2018

   This introduces more complexity than might immediately be apparent.
   In the first place, a 3xx response can convey multiple targets
   through the Contact header field value; and thus the redirecting UAS
   needs to include one nested PASSporT per new target.  Bear in mind as
   well that the original SIP request could have carried multiple
   Identity header field values that had been added by different
   authentication services in the request path.  So a redirecting entity
   might need to generate one nested "div" PASSporT per each PASSporT in
   the original request per each Contact URI in the 3xx.  Often that may
   mean just one "div" PASSporT, but for some deployment scenarios, it
   could require an impractical number of combinations.

   STIR-aware intermediaries that redirect requests MAY therefore convey
   one or more PASSporTs in the backwards direction within Identity
   headers.  This document consequently updates [RFC8224] to permit
   carrying Identity headers in SIP 300-class responses.  It is left to
   authentication services to determine which Identity headers should be
   copied into any new requests resulting from the redirection, if any:
   use of these Identity headers by entities receiving a 3xx response is

   Finally, note that if an intermediary in the response path consumes
   the 3xx and explores new targets itself while performing sequential
   forking, it will effectively retarget the call on behalf of the
   redirecting server, and this will create the same need for "div"
   PASSporTs as any other retargeted call.

6.  Extending 'div' to work with Service Logic Tracking

   It is anticipated that "div" may be used in concert with History-Info
   [RFC7044] in some deployments.  It may not be clear from the "orig"
   and "dest" values which History-Info header a given PASSporT
   correlates to, especially because some of the target changes tracked
   by History-Info will not be reflected in a "div" PASSporT (see
   Section 1).  Therefore an "hi" element may appear in "div"
   corresponding to the History-Info header field index parameter value.
   So for a History-Info header with an index value of "1.2.1", the
   claims object of the corresponding PASSporT with "div" might look

      { "orig":{"tn":"12155551212"},
               "hi":"1.2.1"} }

   Past experience has shown that there may be additional information
   about the motivation for retargeting that relying parties might

Peterson                Expires September 6, 2018               [Page 8]

Internet-Draft              PASSporT Diverted                 March 2018

   consider when making authorization decisions about a call, see for
   example the "reason" associated with the SIP Diversion header field
   [RFC5806].  Future extensions to this specification might incorporate
   reasons into "div".

7.  Acknowledgments

   We would like to thank Robert Sparks for contributions to this

8.  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]

9.  Security Considerations

   This specification describes a security feature, and is primarily
   concerned with increasing security when calls are forwarded.
   Including information about how calls were retargeted during the
   routing process can allow downstream entities to infer particulars of
   the policies used to route calls through the network.  However,
   including this information about forwarding is at the discretion of
   the retargeting entity, so if there is a requirement to keep the
   original called number confidential, no PASSporT should be created
   for that retargeting - the only consequence will be that downstream
   entities will be unable to correlate an incoming call with the
   original PASSporT without access to some prior knowledge of the
   policies that could have caused the retargeting.

10.  Informative References

              Rescorla, E. and J. Peterson, "STIR Out-of-Band
              Architecture and Use Cases", draft-ietf-stir-oob-01 (work
              in progress), October 2017.

Peterson                Expires September 6, 2018               [Page 9]

Internet-Draft              PASSporT Diverted                 March 2018

   [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,

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,

   [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", RFC 8226,
              DOI 10.17487/RFC8226, February 2018,

Peterson                Expires September 6, 2018              [Page 10]

Internet-Draft              PASSporT Diverted                 March 2018

Author's Address

   Jon Peterson
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520


Peterson                Expires September 6, 2018              [Page 11]