PASSporT Extension for Diverted Calls
draft-ietf-stir-passport-divert-05

Document Type Active Internet-Draft (stir WG)
Last updated 2019-03-31 (latest revision 2019-02-19)
Replaces draft-peterson-passport-divert
Stream IETF
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream WG state In WG Last Call
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        J. Peterson
Internet-Draft                                                   Neustar
Updates: RFC8224 (if approved)                         February 19, 2019
Intended status: Standards Track
Expires: August 23, 2019

                 PASSporT Extension for Diverted Calls
                 draft-ietf-stir-passport-divert-05.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 original destination to a new one.  This
   information can greatly improve the decisions made by verification
   services in call forwarding scenarios.  Also specified here is an
   encapsulation mechanism for nesting a PASSporT within another
   PASSporT that assists relying parties in some diversion 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 https://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 August 23, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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

Peterson                 Expires August 23, 2019                [Page 1]
Internet-Draft              PASSporT Diverted              February 2019

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   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.  The 'div' PASSporT Type and Claim . . . . . . . . . . . . . .   4
   4.  Using 'div' in SIP  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Authentication Service Behavior . . . . . . . . . . . . .   6
     4.2.  Verification Service Behavior . . . . . . . . . . . . . .   7
   5.  The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . .   9
   6.  Definition of 'opt' . . . . . . . . . . . . . . . . . . . . .  11
   7.  'div' and Redirection . . . . . . . . . . . . . . . . . . . .  11
   8.  Extending 'div' to work with Service Logic Tracking . . . . .  13
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  'div' registration . . . . . . . . . . . . . . . . . . .  13
     10.2.  'opt' registration . . . . . . . . . . . . . . . . . . .  14
     10.3.  PASSporT Type Registrations  . . . . . . . . . . . . . .  14
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Appendix A: Keys for Examples  . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

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

Peterson                 Expires August 23, 2019                [Page 2]
Internet-Draft              PASSporT Diverted              February 2019

   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
   suspect.

   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
   forwarding" service serves as a good example of the reality that the
   original called party number is not always the number to which a call
   is delivered.  There are a number of potential ways for
   intermediaries to indicate that such a forwarding operating has taken
   place.  The address in the To header field value of SIP requests is
   not supposed to change, according 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.  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 both can 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 the original called number in PASSporT no longer
   reflects the destination to which a call is intended to be delivered.
   For this purpose, it specifies a "div" PASSporT type for use in
   common SIP retargeting cases; it is expected that in this case, SIP
   INVITE requests will carry multiple Identity header fields, each
   containing its own PASSporT.  Verification services and the relying
   parties who make authorization decisions about communications may use
   this diversion indication to confirm that a legitimate retargeting of
   the call has taken place, rather than a cut-and-paste attack.  For
   out-of-band [I-D.ietf-stir-oob] use cases, and other non-SIP
   applications of PASSporT, a separate "div-o" PASSporT type is also
   specified, which defines an "opt" PASSporT element for carrying
   nested PASSporTs within a PASSporT.

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 [RFC2119].

Peterson                 Expires August 23, 2019                [Page 3]
Internet-Draft              PASSporT Diverted              February 2019

3.  The 'div' PASSporT Type and Claim

   This specification defines a PASSporT [RFC8225] type called "div"
   that may be employed by authentication services located at
   retargeting entities.  All "div" PASSporTs MUST contain a new JSON
   Web Token "div" claim, also specified in this document, 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.  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.  The headers of the new
   PASSporTs generated by retargeting entities MUST include the "div"
   PASSporT type, and an "x5u" field pointing to a credential that the
   retargeting entity controls. "div" PASSporTs MUST use full form
   instead of compact form.  The new PASSporT header will look as
   follows:

   { "typ":"passport",
     "ppt":"div",
     "alg":"ES256",
     "x5u":"https://www.example.com/cert.pkx" }

   A "div" PASSporT claims object is populated with elements drawn from
   the PASSporT(s) received for a call by the retargeting entity: 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 claims or extensions are to be copied from the original
   PASSporT to the "div" PASSporT.

   So, for an original PASSporT claims object of the form:

Peterson                 Expires August 23, 2019                [Page 4]
Internet-Draft              PASSporT Diverted              February 2019

      { "orig":{"tn":"12155551212"},
        "dest":{"tn":["12155551213"]},
        "iat":1443208345 }

   If the retargeting entity is changing the target from 12155551213 to
   12155551214, the claims object of a "div" PASSpoRT generated by the
   retargeting entity would look as follows:

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

   The combined full form PASSporT (with a signature covered by the
   ES256 keys given in Appendix A) would look as follows:

    eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \
    oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJkZXN0Ijp7InRuI \
    jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
    0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.YZX3UGjaX \
    sAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cHmaq0Mof2N-bfvRXPXuc \
    htDJm8VbrbQ

   Note that the "div" element may contain other elements than just a
   destination, including a History-Info indicator (see Section 8).
   After the PASSporT header and claims have been constructed, their
   signature is generated per the guidance in [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" claim.

   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 "div" PASSporTs
   to their originals.

   PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6)
   element in their claims; PASSporTs of type "div-o" (see Section 5)
   MUST contain an "opt".

Peterson                 Expires August 23, 2019                [Page 5]
Internet-Draft              PASSporT Diverted              February 2019

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 value
   containing the "div" PASSporT type to a SIP request that already
   contains at least one Identity header field value; it MUST NOT add a
   "div" PASSporT to an INVITE that contains no Identity header field.
   The retargeting entity SHOULD act as a verification service and
   validate the existing Identity header field value(s) in the request
   before proceeding; in some high-volume environments, it may instead
   put that burden of validating the chain entirely on the terminating
   verification service.  As the authentication service will be adding a
   new PASSporT that refers to an original, it MUST NOT remove the
   original request's Identity header field value before forwarding.

   As was stated in Section 3, the authentication service MUST sign any
   "div" PASSporT with a credential that has a scope of authority
   covering the identity it populates in the "div" element value.  Note
   that this is a significant departure from baseline STIR
   authentication service behavior, in which the PASSporT is signed by a
   credential with authority over the "orig" field.  The "div" value
   reflects the URI that caused the call to be routed to the retargeting
   entity, so in ordinary operations, it would already be the STIR
   entity holding the appropriate private keying material for calls
   originating from that identity.

   A SIP authentication service typically will derive the "dest" element
   value of a "div" PASSporT 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 an optional interaction with History-Info below in
   Section 8.  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 retargeting (like History-Info) will likely
   not require a "div" PASSporT.

   When adding an Identity header field with a PASSporT claims object
   containing a "div" claim, SIP authentication services MUST also add a
   "ppt" parameter to that Identity header with a value of "div".  For
   the example PASSporT given in Section 3, the new Identity header
   added after retargeting might look as follows:

Peterson                 Expires August 23, 2019                [Page 6]
Internet-Draft              PASSporT Diverted              February 2019

      Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J \
      0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ.eyJk \
      ZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1 \
      NTEyMTMifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEy \
      MTIifX0.YZX3UGjaXsAYpYEjWAVBcQxNFOFEqIVuhVPPUv-7yhyeKRazMQLjn9cH \
      maq0Mof2N-bfvRXPXuchtDJm8VbrbQ; \
      info=<https://biloxi.example.org/biloxi.cer>;ppt="div"

   Note that in some deployments, an authentication service will need to
   generate "div" PASSporTs for a request that contains multiple
   non-"div" Identity header field values.  For example, a request
   arriving at a retargeting entity might contain in different Identity
   header fields a baseline [RFC8224] PASSporT and a PASSporT of type
   "rph" [I-D.ietf-stir-rph] signed by a separate authority.  Provided
   that these PASSporTs share the same "orig" and "dest" values, the
   retargeting entity's authentication service SHOULD generate only one
   "div" PASSporT.  If the "orig" or "dest" of these PASSporTs differ,
   however, one "div" PASSporT SHOULD be generated for each non-"div"
   PASSporT.  Furthermore note that a request may also be retargeted a
   second time, at which point the subsequent retargeting entity SHOULD
   generate one "div" PASSporT for each previous "div" PASSporT in the
   request.  This can create multiple chains of "div" PASSporTs in a
   single request, which complicates the procedures that need to be
   performed at verification services.

4.2.  Verification Service Behavior

   [RFC8224] Section 6.2 Step 5 requires that specifications defining
   "ppt" values describe any additional or alternative verifier
   behavior.  The job of a SIP verification service handling one or more
   "div" PASSporTs is very different from that of a traditional
   verification service.  At a high level, the immediate responsibility
   of the verification service is to extract all PASSporTs from the two
   or more Identity headers in a request, identify which are "div"
   PASSporTs and which are not, and then order and link the "div"
   PASSporTs to the original PASSporT(s) in order to build one or more
   chains of retargeting.

   In order to validate a SIP request using the "div" PASSporT type, 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.  For each "div" PASSporT, the verification
   service MUST find an earlier PASSporT that contains a "dest" claim
   with a value equivalent to the "div" claim in each "div" 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

Peterson                 Expires August 23, 2019                [Page 7]
Internet-Draft              PASSporT Diverted              February 2019

   a different Identity header field value.  If a complete chain cannot
   be constructed, the verification service cannot complete "div"
   validation; it MAY still validate any non-"div" PASSporTs in the
   request per normal [RFC8224] procedures.  If a chain has been
   successfully constructed, the verification service extracts from the
   outermost (that is, the most recent) PASSporT in the chain a "dest"
   field; this will be a "div" PASSporT that no other "div" PASSporT in
   the SIP request refers to.  Its "dest" element value will be referred
   to in the procedures that follow as the value of the "outermost
   'dest' field."

   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 current destination.  This can
   help the verification service to determine that the original PASSporT
   in the call was not simply used in a cut-and-paste attack and inform
   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 and is thus outside the scope of this
   specification.  A verification service parses a chain of PASSporTs as
   follows:

      First, the verification service MUST compare the value in the
      outermost "dest" field to the target of the call.  As it is
      anticipated that SIP authentication services that create "div"
      PASSporTs will populate the "dest" header from the retargeted
      Request-URI (see Section 4.1), in ordinary SIP operations, the
      Request-URI is where verification services will find the latest
      call target.  Note however that after a "div" PASSporT has been
      added to a SIP request, the Request-URI may have been updated
      during normal call processing to an identifier that no longer
      contains the logical destination of a call; in this case, the
      verification service MAY compare the "dest" field to a provisioned
      telephone number for the recipient.

      Second, the verification service MUST validate the signature over
      the outermost "div" PASSporT, and establish that the credential
      that signed the "div" PASSporT has the authority to attest for the
      identifier in the "div" element of the PASSporT (per [RFC8224]
      Section 6.2 Step 3).

      Third, the verification service MUST validate that the "orig"
      field of the innermost PASSporT of the chain (the only PASSporT in
      the chain which will not be of PASSporT type "div") is equivalent
      to the "orig" field of the outermost "div" PASSporT; in other
      words, that the original calling identifier has not been altered
      by retargeting authentication services.  If the "orig" value has

Peterson                 Expires August 23, 2019                [Page 8]
Internet-Draft              PASSporT Diverted              February 2019

      changed, the verification service MUST treat the entire PASSporT
      chain as invalid.  The verification service SHOULD also verify
      that all other "div" PASSporTs in the chain share the same "orig"
      value.  Then the verification service validates the relationship
      of the "orig" field to the SIP-level call signaling per the
      guidance in [RFC8224] Section 6.2 Step 2.

      Fourth, the verification service MUST check the date freshness in
      the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4.  It
      is furthermore RECOMMENDED that the verification service check
      that the "iat" field of the innermost PASSporT is also within the
      date freshness interval; otherwise the verification service could
      allow attackers to replay an old, stale PASSporT embedded in a
      fresh "div".

      Fifth, the verification service MUST inspect and validate the
      signatures on each and every PASSporT object in the chain between
      the outermost "div" PASSporT and the innermost PASSporT.  Note
      that (per Section 4.1) a chain may terminate at more than one
      innermost PASSporT, in cases where a single "div" is used to
      retarget from multiple based PASSporTs.

   Note that the To header field is not used in the first step above.
   Optionally, the verification service MAY verify that the To header
   field value of the received SIP signaling is equal to the "dest"
   value in the innermost PASSporT; however, as has been observed in
   some deployments, the original To header field value may be altered
   by intermediaries to reflect changes of target.  Deployments that
   change the original To header field value to conceal the original
   destination of the call from the ultimate recipient should note that
   the original destination of a call may be preserved in the innermost
   PASSporT.  Future work on "div" might explore methods to implement
   that sort of policy while retaining a secure chain of redirection.

5.  The 'div-o' PASSporT Type

   This specification defines a "div-o" PASSporT type that uses the
   "div" claim element in conjunction with the opt (Section 6) PASSporT
   claim element.  As is the case with "div" PASSporT type, a "div-o"
   PASSporT is created by an authentication service acting for a
   retargeting entity, but instead of generating a separate "div"
   PASSporT to be conveyed alongside an original PASSporT, the
   authentication service in this case embeds the original PASSporT
   inside the "opt" element of the "div-o" PASSporT.  The "div-o"
   extension is designed for use in non-SIP or gatewayed SIP
   environments where the conveyance of PASSporTs in separate Identity
   header fields in impossible, such as out-of-band [I-D.ietf-stir-oob]
   STIR scenarios.

Peterson                 Expires August 23, 2019                [Page 9]
Internet-Draft              PASSporT Diverted              February 2019

   The syntax of "div-o" PASSporTs is very similar to "div".  A "div-o"
   PASSporT header object might look as follows:

   { "typ":"passport",
     "ppt":"div-o",
     "alg":"ES256",
     "x5u":"https://www.example.com/cert.pkx" }

   Whereas a "div" PASSporT claims object contains only the "orig",
   "dest", "iat", and "div" elements, the "div-o" additionally MUST
   contain an "opt" element (see Section 6), which encapsulates the full
   form of the previous PASSporT from which the call was retargeted,
   triggering the generation of this "div-o".  The value of the "opt"
   element is identical to the base64 encoded PASSporT format given in
   Appendix A of [RFC8225].

   So, for an original PASSporT claims object 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 claims object for "div-o" would look as
   follows:

    { "orig":{"tn":"12155551212"},
      "dest":{"tn":["12155551214"]},
      "iat":1443208345,
      "div":{"tn":"121555551213"},
      "opt":"4F7jsZv0mJ5bjg4Xik6Mfah3IO8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7 \
      c0_0eQi4e9FVX-WmvX3uETtlVjAtgeyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3N \
      wb3J0IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5wa3gifQ. \
      eyJkZXN0Ijp7InRuIjpbIjEyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUs \
      Im9yaWciOnsidG4iOiIxMjE1NTU1MTIxMiJ9fQ.4F7jsZv0mJ5bjg4Xik6Mfah3I \
      O8K6FIsUIgvt0dE7Qm3KZr5UF_UpCrz7c0_0eQi4e9FVX-WmvX3uETtlVjAtg"} }

   While in ordinary operations, it is not expected that SIP would carry
   a "div-o" PASSporT, it might be possible in some gatewaying
   scenarios.  The resulting full form Identity header field with a
   "div-o" PASSporT would look as follows:

Peterson                 Expires August 23, 2019               [Page 10]
Internet-Draft              PASSporT Diverted              February 2019

    Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \
    nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LnBreCJ9.eyJkZX \
    N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \
    In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \
    I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \
    YlhCc1pTNWpiMjB2WTJWeWRDNXdhM2dpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \
    V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \
    T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjRGN2pzWnYwbUo1YmpnNFhpaz \
    ZNZmFoM0lPOEs2RklzVUlndnQwZEU3UW0zS1pyNVVGX1VwQ3J6N2MwXzBlUWk0ZTlG \
    VlgtV212WDN1RVR0bFZqQXRnIiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.M \
    CYorw_3FaH78VuERURlJp1hD6qh2eIct4RIebVtYp3es9HTsvCz1qXRWq3j0E9Pb2h \
    YrMUXSQbBYQSviW5cCA; \
    info=<https://biloxi.example.org/biloxi.cer>;ppt="div-o"

   The authentication and verification service procedures required for
   "div-o" will necessarily be specific to the protocol or environment
   where it is used, and thus are left to future work.

6.  Definition of 'opt'

   The presence of an original PASSporT claims object element,
   designated as "opt", 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 base64 encoded 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, instead redirect with a
   3xx response code.  In ordinary operations, a redirection poses no
   difficulties for the operations of baseline STIR: when the UAC
   receives the 3xx response, it will initiate a new request to the new
   target (typically the target carried in the Contact header field

Peterson                 Expires August 23, 2019               [Page 11]
Internet-Draft              PASSporT Diverted              February 2019

   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" 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 nested "div" PASSporT
   per 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.

   STIR-aware SIP intermediaries that redirect requests MAY therefore
   convey one or more PASSporTs in the backwards direction within
   Identity headers.  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
   headers in SIP 300-class responses.  It is left to the originating
   user agent to determine which Identity headers should be copied from
   the 3xx into any new requests resulting from the redirection, if any:
   use of these Identity headers 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

Peterson                 Expires August 23, 2019               [Page 12]
Internet-Draft              PASSporT Diverted              February 2019

   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 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 object 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 that 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.  Acknowledgments

   We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Eric
   Burger, and Robert Sparks for contributions to this document.

10.  IANA Considerations

   This specification requests that the IANA add two new claims to the
   JSON Web Token Claims registry as defined in [RFC7519].

10.1.  'div' registration

   Claim Name: "div"

   Claim Description: New Target of a Call

   Change Controller: IESG

   Specification Document(s): [RFCThis]

Peterson                 Expires August 23, 2019               [Page 13]
Internet-Draft              PASSporT Diverted              February 2019

10.2.  'opt' registration

   Claim Name: "opt"

   Claim Description: Encapsulated JSON token

   Change Controller: IESG

   Specification Document(s): [RFCThis]

10.3.  PASSporT Type Registrations

   This specification defines two new PASSporT types for the PASSport
   Type Registry defined in [RFC8225].  They are:

      "div" as defined in Section 3.

      "div-o" as defined in Section 5.

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

   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 (with supply a
   "div" per Section 7) mitigates the potential impact.  Under unusual
   traffic loads, even domains that might ordinarily retarget requests
   can switch to redirection.

12.  References

Peterson                 Expires August 23, 2019               [Page 14]
Internet-Draft              PASSporT Diverted              February 2019

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

   [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

   [I-D.ietf-stir-oob]
              Rescorla, E. and J. Peterson, "STIR Out-of-Band
              Architecture and Use Cases", draft-ietf-stir-oob-03 (work
              in progress), July 2018.

Peterson                 Expires August 23, 2019               [Page 15]
Internet-Draft              PASSporT Diverted              February 2019

   [I-D.ietf-stir-rph]
              Singh, R., Dolly, M., Das, S., and A. Nguyen, "PASSporT
              Extension for Resource Priority Authorization", draft-
              ietf-stir-rph-06 (work in progress), May 2018.

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

Appendix A.  Appendix A: Keys for Examples

   The following EC256 keys are used in the signing examples given in
   this document.

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

Author's Address

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

   Email: jon.peterson@team.neustar

Peterson                 Expires August 23, 2019               [Page 16]