Personal Assertion Token (PASSporT) Extension for Diverted Calls
RFC 8946

"dest" claims element of the outermost PASSporT corresponds to the
   called party indication of receive telephone signaling, where such
   indication would vary depending on the using protocol.

   How authentication services or verification services receive or
   transport PASSporTs for "div-o" is outside the scope of this document
   and dependent on the using protocol.

6.  Definition of "opt"

   The presence of an "Original PASSporT" ("opt") claims set element
   signifies that a PASSporT encapsulates another entire PASSporT within
   it, typically a PASSporT that was transformed in some way to create
   the current PASSporT.  Relying parties may need to consult the
   encapsulated PASSporT in order to validate the identity of a caller.
   "opt", as defined in this specification, may be used by future
   PASSporT extensions as well as in conjunction with "div-o".

   "opt" MUST contain a quoted full-form PASSporT, as specified by
   [RFC8225], Appendix A; it MUST NOT contain a compact form PASSporT.
   For an example of a "div-o" PASSporT containing "opt", see Section 5.

7.  "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 the original PASSporT "dest" value
   designates a different destination.

   Any intermediary that assigns a new target to a request can, instead
   of retargeting and forwarding the request, redirect with a 3xx
   response code.  In ordinary operations, a redirection poses no
   difficulties for the operations of baseline STIR: when the user agent
   client (UAC) receives the 3xx response, it will initiate a new
   request to the new target (typically the target 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
   requirements 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 for that assertion 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.

   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; to accommodate this, the
   "div" PASSporT MAY include one "dest" object array value per Contact,
   but if the retargeting entity wants to keep the Contact list private
   from targets, it may need to generate one PASSporT per Contact.  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 "div" PASSporT for each
   PASSporT in the original request.  Often, this will mean just one
   "div" PASSporT, but for some deployment scenarios, it could require
   an impractical number of combinations.  But in very complex call
   routing scenarios, attestation of source identity would only add
   limited value anyway.

   Therefore, STIR-aware SIP intermediaries that redirect requests MAY
   convey one or more PASSporTs in the backwards direction within
   Identity header fields.  These redirecting entities will act as
   authentication services for "div" as described in Section 4.1.  This
   document consequently updates [RFC8224] to permit carrying Identity
   header fields in SIP 300-class responses.  It is left to the
   originating user agent to determine which Identity header fields
   should be copied from the 3xx into any new requests resulting from
   the redirection, if any; use of these Identity header fields by
   entities receiving a 3xx response is OPTIONAL.

   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.  These intermediaries MAY
   also copy PASSporTs from the 3xx response and insert them into
   sequential forking requests, if appropriate.

8.  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 as defined here may appear in
   "div" corresponding to the History-Info header field index parameter
   value.  So for a History-Info header field with an index value of
   "1.2.1", the claims set of the corresponding PASSporT with "div"
   might look like:

      { "orig":{"tn":"12155551212"},
        "dest":{"tn":["12155551214"]},
        "iat":1443208345,
        "div":{"tn":"121555551213",
               "hi":"1.2.1"} }

   Past experience has shown that there may be additional information
   about the motivation for retargeting, which relying parties might
   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".

9.  IANA Considerations

9.1.  JSON Web Token Claims Registrations

   Per this specification, IANA has added two new claims to the "JSON
   Web Token Claims" registry as defined in [RFC7519].

9.1.1.  "div" registration

   Claim Name:  div

   Claim Description:  Diverted Target of a Call

   Change Controller:  IESG

   Reference:  RFC 8946

9.1.2.  "opt" registration

   Claim Name:  opt

   Claim Description:  Original PASSporT (in Full Form)

   Change Controller:  IESG

   Reference:  RFC 8946

9.2.  PASSporT Type Registrations

   This specification defines two new PASSporT types for the "Personal
   Assertion Token (PASSporT) Extensions" registry defined in [RFC8225],
   which resides at <https://www.iana.org/assignments/passport>.  They
   are:

   *  "div", as defined in Section 3.

   *  "div-o", as defined in Section 5.

10.  Privacy Considerations

   There is an inherent trade-off in any mechanism that tracks, in SIP
   signaling, how calls are routed through a network, as routing
   decisions may expose policies set by users for how calls are
   forwarded, potentially revealing relationships between different
   identifiers representing the same user.  Note, however, that in
   ordinary operations, this information is revealed to the user agent
   service of the called party, not the calling party.  It is usually
   the called party who establishes these forwarding relationships, and
   if indeed some other party is responsible for calls being forwarded
   to the called party, many times the called party should likely be
   entitled to information about why they are receiving these calls.
   Similarly, a redirecting entity who sends a 3xx in the backwards
   direction knowingly shares information about service logic with the
   caller's network.  However, as there may be unforeseen circumstances
   where the revelation of service logic to the called party poses a
   privacy risk, implementers and users of this or similar diversion-
   tracking techniques should understand the trade-off.

   Furthermore, it is a general privacy risk of identity mechanisms
   overall that they do not interface well with anonymization services;
   the interaction of STIR with anonymization services is detailed in
   [RFC8224], Section 11.  Any forwarding service that acts as an
   anonymizing proxy may not be able to provide a secure chain of
   retargeting due to the obfuscation of the originating identity.

   Also see [RFC8224], Section 11 for further considerations on the
   privacy of using PASSporTs in SIP.

11.  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 an
   intermediate 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.

   Any extension that makes PASSporTs larger creates a potential
   amplification mechanism for SIP-based DDoS attacks.  Since diversion
   PASSporTs are created as a part of normal forwarding activity, this
   risk arises at the discretion of the retargeting domain; simply using
   3xx response redirections rather than retargeting (by supplying a
   "div" per Section 7) mitigates the potential impact.  Under unusual
   traffic loads, even domains that might ordinarily retarget requests
   can switch to redirection.

   SIP has an inherent capability to redirect requests, including
   forking them to multiple parties -- potentially, a very large number
   of parties.  The use of the "div" PASSporT type does not grant any
   additional powers to attackers who hope to place bulk calls; if
   present, the "div" PASSporT instead identifies the party responsible
   for the forwarding.  As such, senders of bulk unsolicited traffic are
   unlikely to find the use of "div" attractive.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc3261>.

   [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,
              <https://www.rfc-editor.org/info/rfc7044>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc8224>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/info/rfc8225>.

   [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", RFC 8226,
              DOI 10.17487/RFC8226, February 2018,
              <https://www.rfc-editor.org/info/rfc8226>.

12.2.  Informative References

   [RFC5806]  Levy, S. and M. Mohali, Ed., "Diversion Indication in
              SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010,
              <https://www.rfc-editor.org/info/rfc5806>.

   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
              Telephone Identity Problem Statement and Requirements",
              RFC 7340, DOI 10.17487/RFC7340, September 2014,
              <https://www.rfc-editor.org/info/rfc7340>.

   [RFC8443]  Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal
              Assertion Token (PASSporT) Extension for Resource Priority
              Authorization", RFC 8443, DOI 10.17487/RFC8443, August
              2018, <https://www.rfc-editor.org/info/rfc8443>.

   [RFC8816]  Rescorla, E. and J. Peterson, "Secure Telephone Identity
              Revisited (STIR) Out-of-Band Architecture and Use Cases",
              RFC 8816, DOI 10.17487/RFC8816, February 2021,
              <https://www.rfc-editor.org/info/rfc8816>.

Appendix A.  Keys for Examples

   The following EC256 keys are used in the signing examples given in
   this document.  WARNING: Do not use this key pair in production
   systems.

   -----BEGIN PUBLIC KEY-----
   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4
   hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
   -----END PUBLIC KEY-----

   -----BEGIN EC PRIVATE KEY-----
   MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49
   AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4
   +Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w==
   -----END EC PRIVATE KEY-----

Acknowledgments

   We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean
   Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks
   for contributions to this document.

Author's Address

   Jon Peterson
   Neustar, Inc.
   1800 Sutter St., Suite 570
   Concord, CA 94520
   United States of America

   Email: jon.peterson@team.neustar