Out-of-Band STIR for Service Providers
draft-peterson-stir-servprovider-oob-00

Network Working Group                                        J. Peterson
Internet-Draft                                                   Neustar
Intended status: Informational                             March 9, 2020
Expires: September 10, 2020

                 Out-of-Band STIR for Service Providers
                draft-peterson-stir-servprovider-oob-00

Abstract

   The Secure Telephone Identity Revisited (STIR) framework defines
   means of carrying its Persona Assertion Tokens (PASSporTs) either in-
   band, within the headers of a SIP request, or out-of-band, through a
   service that stores PASSporTs for retrieval by relying parties.  This
   specification defines a way that the out-of-band conveyance of
   PASSporTs can be used to support large service providers, for cases
   in which in-band STIR conveyance is not universally available.

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 September 10, 2020.

Copyright Notice

   Copyright (c) 2020 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
   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 10, 2020               [Page 1]
Internet-Draft            Service Provider OOB                March 2020

   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.  Service Provider Deployment Architecture for Out-of-Band STIR   3
   4.  Advertising a CPS . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Submitting a PASSporT . . . . . . . . . . . . . . . . . . . .   4
   6.  PASSporT Retrieval  . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   STIR [RFC8224] provides a cryptographic assurance of the identity of
   calling parties in order to prevent impersonation, which is a key
   enabler of unwanted robocalls, swatting, vishing, voicemail hacking,
   and similar attacks (see [RFC7340]).  The STIR out-of-band
   [I-D.ietf-stir-oob] framework enables the delivery of PASSporT
   [RFC8225] objects through a Call Placement Service (CPS), rather than
   carrying them within a signaling protocol such as SIP.  Out-of-band
   conveyance is valuable when end-to-end SIP delivery of calls is
   partly or entirely unavailable due to network border policies, calls
   routinely transitting a gateway to the PSTN, or similar
   circumstances.

   While out-of-band STIR can be implemented as an open Internet
   service, it then requires complex security measures to enable the CPS
   function without allowing the CPS to collect data about the parties
   placing calls.  This specification describes CPS implementations that
   act specifically on behalf of service providers who will be
   processing the calls that STIR secures, and who thus will learn about
   the parties to communication independently, so an alternative
   security architecture becomes possible.

   Environments that might support this flavor of STIR out-of-band
   include carriers, large enterprises, call centers, or any Internet
   service that aggregates on behalf of a large number of telephone
   endpoints.

Peterson               Expires September 10, 2020               [Page 2]
Internet-Draft            Service Provider OOB                March 2020

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Service Provider Deployment Architecture for Out-of-Band STIR

   The architecture in this specification assumes that every
   participating service provider will advertise one or more designated
   CPS instances.  A service provider's CPS serves as a place where
   callers can deposit a PASSporT when attempting to place a call to a
   subscriber of the destination service provider; if the caller's
   domain supports in-band STIR, this can be done at the same time as an
   in-band STIR call is placed.  The terminating service provider could
   operate the CPS themselves, or a third party could operate the CPS on
   the destination's behalf.  This model does not assume a monolithic
   CPS that acts on behalf of all service providers, but nor does it
   prohibit multiple service providers from sharing a CPS provider.

   The process of locating a destination CPS and submitting a PASSporT
   requires Internet connectivity between the call originator and the
   destination network.  Ordinarily, that network connectivity could be
   leveraged to initiate a SIP session, in which in-band STIR could be
   used.  The applicability of this architecture is therefore to those
   cases where, for whatever reason, SIP calls cannot reliably be placed
   end-to-end, but an HTTP transaction can reliably be sent to the
   destination network from the out-of-band authentication service (OOB-
   AS) in the caller's network.  It is hoped that as IP connectivity
   between telephone providers increases, there will be less need for an
   out-of-band mechanism, but it can serve as a fallback mechanism in
   cases where service providers cannot predict whether end-to-end
   delivery of SIP calls will occur.

4.  Advertising a CPS

   Many services providers have bilateral agreements to peer with one
   another, and in those environments, identifying their respective
   CPS's could be a simple matter of provisioning.  In more open
   environments, some mechanism is needed to discover the CPS associated
   with the target of a call.

   In order to allow the CPS chosen by a service provider to be
   discovered securely, this specification defines a CPS advertisement.
   Effectively, a CPS advertisement is a document signed with a STIR
   [RFC8226] credential which contains the URL of a CPS, and optionally

Peterson               Expires September 10, 2020               [Page 3]
Internet-Draft            Service Provider OOB                March 2020

   information about which PASSporTs for calls should be submitted to
   that CPS.  This information is optional because STIR certificates
   themselves contain a "TNAuthList" value that can indicate the
   telephone network resources that a service provider controls; in the
   absence of any optional information in the CPS advertisement, the
   TNAuthList of the signing certificate

   The format of a service provider CPS advertisement is a simple JSON
   object containing a "cps" element with a value equal to the URI of
   the CPS.  These MUST be HTTPS URIs.  [More TBD].

   CPS advertisements could be made available through existing or new
   databases.  They could be discovered during the call routing process,
   including through a DNS lookup.  They could be shared through a
   distributed database among the participants in a multilateral peering
   arrangement.

   An alternative to CPS advertisements that may be usable in some
   environments is adding a field to STIR [RFC8226] credentials issued
   to individual service providers.  As these certificates are
   themselves signed by a CA, the URI would be bound securely to the
   service provider.  As STIR assumes a community of relying parties who
   trust these credentials, this method perhaps best mirrors the trust
   model required to allow a CPS to authorize PASSporT submission and
   retrieval.

5.  Submitting a PASSporT

   Submitting a PASSporT to a CPS as specified in the STIR out-of-band
   framework [I-D.ietf-stir-oob] requires security measures which are
   intended to prevent the CPS from learning the identity of the caller
   (or callee), to the degree possible.  In this service provider case,
   however, the CPS is operated by the service provider of the callee
   (or an entity operating on their behalf), and as such the information
   that appears in the PASSporT is redundant with call signaling that
   the terminating party will receive anyway.  Therefore, the service
   provider out-of-band framework does not attempt to conceal the
   identity of the originating or terminating party from the CPS.

   An out-of-band authentication service (OOB-AS) forms a secure
   connection with the target CPS.  This may happen at the time a call
   is being placed, or it may be a persistent connection, if there is a
   significant volume of traffic sent over this interface.  The OOB-AS
   authenticates itself to the CPS using its STIR credential
   [RFC8226]the same one it would use to sign calls; this helps mitigate
   the risk of flooding that more open OOB implementations may face.  A
   CPS makes its own policy decision as to whether it will accept calls
   from a particular OOB-AS, and at what volumes.

Peterson               Expires September 10, 2020               [Page 4]
Internet-Draft            Service Provider OOB                March 2020

   Service provider out-of-band PASSporTs do not need to be encrypted
   for storage at the CPS, although use of transport-layer security to
   prevent eavesdropping on the connection between the CPS and OOB-ASs
   is REQUIRED.  PASSporTs will be submitted to the CPS at the time they
   are created by an AS; if the PASSporT is also being used for in-band
   transit within a SIP request, the PASSporT can be submitted to the
   CPS before or after the SIP request is sent, at the discretion of the
   originating domain.  An OOB-AS will use a REST interface to submit
   PASSporTs to the CPS as described in [I-D.ietf-stir-oob] Section 9
   [more TBD].  PASSporTs are persisted by the CPS for as long as is
   required for them to be retrieved (see the next section), but in any
   event for no longer than the freshness interval of the PASSporT
   itself (a maximum of sixty seconds).

6.  PASSporT Retrieval

   The STIR out-of-band framework [I-D.ietf-stir-oob] proposes two means
   that called parties can acquire PASSporTs out-of-band: through a
   retrieval interface, or through a subscription interface.  In the
   service provider context, where many calls occur simultaneously, an
   out-of-band capable verification service may therefore operate in one
   of two modes: it can either pull PASSporTs from the CPS after calls
   arrive, or receive push notifications from the CPS for incoming
   calls.

   If a CPS serves only one service provider, then all PASSporTs
   submitted to the CPS are made available to the OOB-VS of that
   provider; indeed, the CPS and OOB-VS may be colocated or effectively
   operated as a consolidated system.  In a multi-provider environment,
   the STIR credential of the terminating domain can be used by the CPS
   to determine the range of telephone numbers for which an OOB-VS is
   entitled to receive PASSporTs.  Note that a CPS will need to inspect
   the "dest" element of a PASSporT to determine which OOB-VS should
   receive the PASSporT in this case.

   Pulling of PASSporTs from the CPS will follow the basic REST flow
   described in [I-D.ietf-stir-oob] Section 9.  In the push interface
   case, exactly how a CPS determines which PASSporTs to send to an out-
   of-band verification service is a matter of implementation.  An OOB-
   VS could for example subscribe to a range of telephone numbers, which
   will be directed to that OOB-VS by the CPS (provided the OOB-VS is
   authorized to receive them by the CPS).

   [TBD: Which sub/not protocol to use for this case?]

   In the pull model, a terminating service provider contacts the CPS
   via its OOB-VS after having received a call in cases when the call
   signaling does not itself carry a STIR signature.  In the push model,

Peterson               Expires September 10, 2020               [Page 5]
Internet-Draft            Service Provider OOB                March 2020

   a PASSporT might be sent to the OOB-VS either before or after
   unsigned call signaling has been received by the terminating domain.
   Domains using the push model may therefore need to adopt a model
   where call signaling is held momentarily in order to await the
   potential arrival of a PASSporT at the OOB-VS.  The exact timing of
   this, and its interaction with the substitution attack described in
   [I-D.ietf-stir-oob] Section 7.4, will be the covered by future
   versions of this specification.

7.  Acknowledgments

   We would like to thank YOU for your contributions to this
   specification.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   TBD.

10.  Informative References

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

   [I-D.ietf-stir-passport-divert]
              Peterson, J., "PASSporT Extension for Diverted Calls",
              draft-ietf-stir-passport-divert-08 (work in progress),
              March 2020.

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

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
              2002, <https://www.rfc-editor.org/info/rfc3311>.

Peterson               Expires September 10, 2020               [Page 6]
Internet-Draft            Service Provider OOB                March 2020

   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
              2007, <https://www.rfc-editor.org/info/rfc4916>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

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

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

Author's Address

   Jon Peterson
   Neustar, Inc.

   Email: jon.peterson@neustar.biz

Peterson               Expires September 10, 2020               [Page 7]