Internet DRAFT - draft-peterson-stir-servprovider-oob
draft-peterson-stir-servprovider-oob
Network Working Group J. Peterson
Internet-Draft Neustar
Intended status: Informational July 13, 2020
Expires: January 14, 2021
Out-of-Band STIR for Service Providers
draft-peterson-stir-servprovider-oob-01
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 January 14, 2021.
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 January 14, 2021 [Page 1]
Internet-Draft Service Provider OOB July 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. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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 January 14, 2021 [Page 2]
Internet-Draft Service Provider OOB July 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, during 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 pluralist
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 which contains the URL
of a CPS, as well as any information needed to determine which
Peterson Expires January 14, 2021 [Page 3]
Internet-Draft Service Provider OOB July 2020
PASSporTs should be submitted to that CPS. An advertisement may be
signed with a STIR [RFC8226] credential, or another credential that
is trusted by the participants in a given STIR environment. The
advantage to signing with STIR certificates is that they contain a
"TNAuthList" value indicating the telephone network resources that a
service provider controls. This information can be matched with a
TNAuthList value in the CPS advertisement to determine whether the
signer has the authority to advertise a particular CPS as the proper
destination for PASSporTs.
The format of a service provider CPS advertisement is a simple JSON
object containing one or more pairs of TNAuthList values pointing to
the URIs of CPSs, e.g. { "1234":"https://cps.example.com" }.
TNAuthList values can be either Service Provider Codes (SPCs) or
telephone numbers or number ranges. CPS URIs MUST be HTTPS URIs.
[More TBD].
CPS advertisements could be made available through existing or new
databases, potentially aggregated across multiple service providers
and distributed to call originators as necessary. 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
Peterson Expires January 14, 2021 [Page 4]
Internet-Draft Service Provider OOB July 2020
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
SHOULD authenticate itself to the CPS using its STIR credential
[RFC8226]the same one it would use to sign calls via mutual TLS; this
helps mitigate the risk of flooding that more open OOB
implementations may face. Furthermore, use of mutual TLS prevents
attackers from replaying captured PASSporTs to the CPS. A CPS makes
its own policy decision as to whether it will accept calls from a
particular OOB-AS, and at what volumes.
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 TNAuthLists 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. [TBD: Which sub/not protocol to use for
the case where the CPS and OOB-VS are not composed in a single
function?]
Peterson Expires January 14, 2021 [Page 5]
Internet-Draft Service Provider OOB July 2020
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).
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,
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. Gateways
In some deployment architectures, gateways might perform a function
that interfaces with a CPS for the retrieval or storage of PASSporTs.
For example, a closed network of in-band STIR providers may send SIP
INVITEs to a gateway in front of a traditional PSTN tandem that
services a set of legacy service providers. In that environment, a
gateway might take a PASSporT out of in-band SIP INVITEs and store it
in a CPS that was established to handle requests for one or more
legacy providers, who in turn consume those PASSporTs through an OOB-
VS to assist in robocall mitigation and similar functions.
The simplest way to interface a gateway performing this sort of
function for a service provider CPS system is to issue credentials to
the gateway that allow it to act on behalf of the legacy service
providers it supports: this would allow it to both add PASSporTs to
the CPS acting on behalf of the legacy providers, and also to create
PASSporTs for in-band STIR conveyance from the legacy-providers to
terminating service providers in the closed STIR network.
8. Acknowledgments
We would like to thank Alex Fenichel for contributions to this
specification.
Peterson Expires January 14, 2021 [Page 6]
Internet-Draft Service Provider OOB July 2020
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
TBD.
11. Informative References
[I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), March 2020.
[I-D.ietf-stir-passport-divert]
Peterson, J., "PASSporT Extension for Diverted Calls",
draft-ietf-stir-passport-divert-09 (work in progress),
July 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>.
[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>.
Peterson Expires January 14, 2021 [Page 7]
Internet-Draft Service Provider OOB July 2020
[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 January 14, 2021 [Page 8]