draft-ietf-stir-servprovider-oob-00.txt   draft-ietf-stir-servprovider-oob-01.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Informational November 2, 2020 Intended status: Informational February 22, 2021
Expires: May 6, 2021 Expires: August 26, 2021
Out-of-Band STIR for Service Providers Out-of-Band STIR for Service Providers
draft-ietf-stir-servprovider-oob-00 draft-ietf-stir-servprovider-oob-01
Abstract Abstract
The Secure Telephone Identity Revisited (STIR) framework defines The Secure Telephone Identity Revisited (STIR) framework defines
means of carrying its Persona Assertion Tokens (PASSporTs) either in- means of carrying its Persona Assertion Tokens (PASSporTs) either in-
band, within the headers of a SIP request, or out-of-band, through a band, within the headers of a SIP request, or out-of-band, through a
service that stores PASSporTs for retrieval by relying parties. This service that stores PASSporTs for retrieval by relying parties. This
specification defines a way that the out-of-band conveyance of specification defines a way that the out-of-band conveyance of
PASSporTs can be used to support large service providers, for cases PASSporTs can be used to support large service providers, for cases
in which in-band STIR conveyance is not universally available. in which in-band STIR conveyance is not universally available.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on August 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Service Provider Deployment Architecture for Out-of-Band STIR 3 3. Service Provider Deployment Architecture for Out-of-Band STIR 3
4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 3 4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 3
5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 4 5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 5
6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 5 6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 6
7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. Informative References . . . . . . . . . . . . . . . . . . . 7 11. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
STIR [RFC8224] provides a cryptographic assurance of the identity of STIR [RFC8224] provides a cryptographic assurance of the identity of
calling parties in order to prevent impersonation, which is a key calling parties in order to prevent impersonation, which is a key
enabler of unwanted robocalls, swatting, vishing, voicemail hacking, enabler of unwanted robocalls, swatting, vishing, voicemail hacking,
and similar attacks (see [RFC7340]). The STIR out-of-band and similar attacks (see [RFC7340]). The STIR out-of-band
[I-D.ietf-stir-oob] framework enables the delivery of PASSporT [I-D.ietf-stir-oob] framework enables the delivery of PASSporT
[RFC8225] objects through a Call Placement Service (CPS), rather than [RFC8225] objects through a Call Placement Service (CPS), rather than
carrying them within a signaling protocol such as SIP. Out-of-band carrying them within a signaling protocol such as SIP. Out-of-band
skipping to change at page 2, line 43 skipping to change at page 2, line 43
routinely transitting a gateway to the PSTN, or similar routinely transitting a gateway to the PSTN, or similar
circumstances. circumstances.
While out-of-band STIR can be implemented as an open Internet While out-of-band STIR can be implemented as an open Internet
service, it then requires complex security measures to enable the CPS service, it then requires complex security measures to enable the CPS
function without allowing the CPS to collect data about the parties function without allowing the CPS to collect data about the parties
placing calls. This specification describes CPS implementations that placing calls. This specification describes CPS implementations that
act specifically on behalf of service providers who will be act specifically on behalf of service providers who will be
processing the calls that STIR secures, and who thus will learn about processing the calls that STIR secures, and who thus will learn about
the parties to communication independently, so an alternative the parties to communication independently, so an alternative
security architecture becomes possible. security architecture becomes possible. These functions may be
crucial to the adoption of STIR in some environments, like mobile
networks, where in-band transmission of STIR may not be feasible.
Environments that might support this flavor of STIR out-of-band Environments that might support this flavor of STIR out-of-band
include carriers, large enterprises, call centers, or any Internet include carriers, large enterprises, call centers, or any Internet
service that aggregates on behalf of a large number of telephone service that aggregates on behalf of a large number of telephone
endpoints. endpoints. That last case may include certain classes of gateway or
transit providers.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Service Provider Deployment Architecture for Out-of-Band STIR 3. Service Provider Deployment Architecture for Out-of-Band STIR
The architecture in this specification assumes that every The architecture in this specification assumes that every
participating service provider will advertise one or more designated participating service provider is associated with one or more
CPS instances. A service provider's CPS serves as a place where designated CPS instances. A service provider's CPS serves as a place
callers can deposit a PASSporT when attempting to place a call to a where callers, or in some cases gateways, can deposit a PASSporT when
subscriber of the destination service provider; if the caller's attempting to place a call to a subscriber of the destination service
domain supports in-band STIR, this can be done at the same time as an provider; if the caller's domain supports in-band STIR, this can be
in-band STIR call is placed. The terminating service provider could done at the same time as an in-band STIR call is placed. The
operate the CPS themselves, or a third party could operate the CPS on terminating service provider could operate the CPS themselves, or a
the destination's behalf. This model does not assume a monolithic third party could operate the CPS on the destination's behalf. This
CPS that acts on behalf of all service providers, but nor does it model does not assume a monolithic CPS that acts on behalf of all
prohibit multiple service providers from sharing a CPS provider. service providers, but nor does it prohibit multiple service
Moreover, a particular CPS can be a logically distributed entity providers from sharing a CPS provider. Moreover, a particular CPS
compromised of several geographically distant entities that flood can be a logically distributed entity compromised of several
PASSporTs among themselves to support an anycast-like service. geographically distant entities that flood PASSporTs among themselves
to support an anycast-like service.
The process of locating a destination CPS and submitting a PASSporT The process of locating a destination CPS and submitting a PASSporT
requires Internet connectivity between the call originator and the naturally requires Internet connectivity to the CPS. If the CPS is
CPS. If the CPS is deployed in the terminating service provider deployed in the terminating service provider network, that network
network, that network connectivity could be leveraged to initiate a connectivity could be leveraged by a caller to initiate a SIP
SIP session, during which in-band STIR could be used. The session, during which in-band STIR could be used normally. The
applicability of this architecture is therefore to those cases where, applicability of this architecture is therefore to those cases where,
for whatever reason, SIP calls cannot reliably be placed end-to-end, for whatever reason, SIP requests cannot reliably convey PASSporTs
but an HTTP transaction can reliably be sent to the destination end-to-end, but an HTTP transaction can reliably be sent to the
network from the out-of-band authentication service (OOB-AS) in the destination network from the out-of-band authentication service (OOB-
caller's network. It is hoped that as IP connectivity between AS). It is hoped that as IP connectivity between telephone providers
telephone providers increases, there will be less need for an out-of- increases, there will be less need for an out-of-band mechanism, but
band mechanism, but it can serve as a fallback mechanism in cases it can serve as a fallback mechanism in cases where service providers
where service providers cannot predict whether end-to-end delivery of cannot predict whether end-to-end delivery of SIP calls will occur.
SIP calls will occur.
4. Advertising a CPS 4. Advertising a CPS
If more than one CPS exists for a given deployment, there will need If more than one CPS exists for a given deployment, there will need
to be some means of discovering CPSs, either administratively or to be some means of discovering CPSs, either administratively or
programmatically. Many services providers have bilateral agreements programmatically. Many services providers have bilateral agreements
to peer with one another, and in those environments, identifying to peer with one another, and in those environments, identifying
their respective CPS's could be a simple matter of provisioning. A their respective CPS's could be a simple matter of provisioning. A
consortium of service providers could simply agree to choose from a consortium of service providers could simply agree to choose from a
list of available CPS providers, say. In more pluralist list of available CPS providers, say. In more pluralist
environments, some mechanism is needed to discover the CPS associated environments, some mechanism is needed to discover the CPS associated
with the target of a call. with the target of a call.
In order to allow the CPS chosen by a service provider to be In order to allow the CPS chosen by a service provider to be
discovered securely, this specification defines a CPS advertisement. discovered securely, this specification defines a CPS advertisement.
Effectively, a CPS advertisement is a document which contains the URL Effectively, a CPS advertisement is a document which contains the URL
of a CPS, as well as any information needed to determine which of a CPS, as well as any information needed to determine which
PASSporTs should be submitted to that CPS. An advertisement may be PASSporTs should be submitted to that CPS (e.g., Service Provider
Codes (SPCs) or telephone number ranges). An advertisement may be
signed with a STIR [RFC8226] credential, or another credential that signed with a STIR [RFC8226] credential, or another credential that
is trusted by the participants in a given STIR environment. The is trusted by the participants in a given STIR environment. The
advantage to signing with STIR certificates is that they contain a advantage to signing with STIR certificates is that they contain a
"TNAuthList" value indicating the telephone network resources that a "TNAuthList" value indicating the telephone network resources that a
service provider controls. This information can be matched with a service provider controls. This information can be matched with a
TNAuthList value in the CPS advertisement to determine whether the TNAuthList value in the CPS advertisement to determine whether the
signer has the authority to advertise a particular CPS as the proper signer has the authority to advertise a particular CPS as the proper
destination for PASSporTs. destination for PASSporTs.
The format of a service provider CPS advertisement is a simple JSON The format of a service provider CPS advertisement is a simple JSON
object containing one or more pairs of TNAuthList values pointing to object containing one or more pairs of TNAuthList values pointing to
the URIs of CPSs, e.g. { "1234":"https://cps.example.com" }. the URIs of CPSs, e.g. { "1234":"https://cps.example.com" }.
TNAuthList values can be either Service Provider Codes (SPCs) or TNAuthList values can be either Service Provider Codes (SPCs) or
telephone numbers or number ranges. CPS URIs MUST be HTTPS URIs. telephone numbers or number ranges. CPS URIs MUST be HTTPS URIs.
[More TBD]. These CPS URIs SHOULD be publicly reachable, as service providers
cannot usually anticipate all of the potential callers that might
want to connect with them, but in more constrained environments, they
MAY be only reachable over a closed network.
CPS advertisements could be made available through existing or new CPS advertisements could be made available through existing or new
databases, potentially aggregated across multiple service providers databases, potentially aggregated across multiple service providers
and distributed to call originators as necessary. They could be and distributed to call originators as necessary. They could be
discovered during the call routing process, including through a DNS discovered during the call routing process, including through a DNS
lookup. They could be shared through a distributed database among lookup. They could be shared through a distributed database among
the participants in a multilateral peering arrangement. the participants in a multilateral peering arrangement.
An alternative to CPS advertisements that may be usable in some An alternative to CPS advertisements that may be usable in some
environments is adding a field to STIR [RFC8226] credentials issued environments is adding a field to STIR [RFC8226] certificates
to individual service providers. As these certificates are identifying the CPS URI issued to individual service providers. As
themselves signed by a CA, the URI would be bound securely to the these certificates are themselves signed by a CA, and contain their
service provider. As STIR assumes a community of relying parties who own TNAuthList, the URI would be bound securely to the proper
trust these credentials, this method perhaps best mirrors the trust telephone network identifiers. As STIR assumes a community of
model required to allow a CPS to authorize PASSporT submission and relying parties who trust these credentials, this method perhaps best
retrieval. mirrors the trust model required to allow a CPS to authorize PASSporT
submission and retrieval.
5. Submitting a PASSporT 5. Submitting a PASSporT
Submitting a PASSporT to a CPS as specified in the STIR out-of-band 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 framework [I-D.ietf-stir-oob] requires security measures which are
intended to prevent the CPS from learning the identity of the caller intended to prevent the CPS from learning the identity of the caller
(or callee), to the degree possible. In this service provider case, (or callee), to the degree possible. In this service provider case,
however, the CPS is operated by the service provider of the callee however, the CPS is operated by the service provider of the callee
(or an entity operating on their behalf), and as such the information (or an entity operating on their behalf), and as such the information
that appears in the PASSporT is redundant with call signaling that that appears in the PASSporT is redundant with call signaling that
the terminating party will receive anyway. Therefore, the service the terminating party will receive anyway. Therefore, the service
provider out-of-band framework does not attempt to conceal the provider out-of-band framework does not attempt to conceal the
identity of the originating or terminating party from the CPS. identity of the originating or terminating party from the CPS.
An out-of-band authentication service (OOB-AS) forms a secure An out-of-band authentication service (OOB-AS) forms a secure
connection with the target CPS. This may happen at the time a call 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 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 significant volume of traffic sent over this interface. The OOB-AS
SHOULD authenticate itself to the CPS using its STIR credential SHOULD authenticate itself to the CPS via mutual TLS using its STIR
[RFC8226]the same one it would use to sign calls via mutual TLS; this credential [RFC8226], the same one it would use to sign calls; this
helps mitigate the risk of flooding that more open OOB helps mitigate the risk of flooding that more open OOB
implementations may face. Furthermore, use of mutual TLS prevents implementations may face. Furthermore, use of mutual TLS prevents
attackers from replaying captured PASSporTs to the CPS. A CPS makes attackers from replaying captured PASSporTs to the CPS. A CPS makes
its own policy decision as to whether it will accept calls from a its own policy decision as to whether it will accept calls from a
particular OOB-AS, and at what volumes. particular OOB-AS, and at what volumes. A CPS can use this mechanism
can authorize service providers who already hold STIR credentials to
submit PASSporTs to a CPS, but alternative mechanisms would be
required for any entities that do not hold a STIR credential,
including gateway or transit providers who want to submit PASSporTs.
See Section 7 below for more on their behavior.
Service provider out-of-band PASSporTs do not need to be encrypted Service provider out-of-band PASSporTs do not need to be encrypted
for storage at the CPS, although use of transport-layer security to for storage at the CPS, although use of transport-layer security to
prevent eavesdropping on the connection between the CPS and OOB-ASs prevent eavesdropping on the connection between the CPS and OOB-ASs
is REQUIRED. PASSporTs will be submitted to the CPS at the time they is REQUIRED. PASSporTs will typically be submitted to the CPS at the
are created by an AS; if the PASSporT is also being used for in-band time they are created by an AS; if the PASSporT is also being used
transit within a SIP request, the PASSporT can be submitted to the for in-band transit within a SIP request, the PASSporT can be
CPS before or after the SIP request is sent, at the discretion of the submitted to the CPS before or after the SIP request is sent, at the
originating domain. An OOB-AS will use a REST interface to submit discretion of the originating domain. An OOB-AS will use a REST
PASSporTs to the CPS as described in [I-D.ietf-stir-oob] Section 9 interface to submit PASSporTs to the CPS as described in
[more TBD]. PASSporTs are persisted by the CPS for as long as is [I-D.ietf-stir-oob] Section 9 [more TBD]. PASSporTs persist at the
required for them to be retrieved (see the next section), but in any CPS for as long as is required for them to be retrieved (see the next
event for no longer than the freshness interval of the PASSporT section), but in any event for no longer than the freshness interval
itself (a maximum of sixty seconds). of the PASSporT itself (a maximum of sixty seconds).
6. PASSporT Retrieval 6. PASSporT Retrieval
The STIR out-of-band framework [I-D.ietf-stir-oob] proposes two means 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 that called parties can acquire PASSporTs out-of-band: through a
retrieval interface, or through a subscription interface. In the retrieval interface, or through a subscription interface. In the
service provider context, where many calls occur simultaneously, an service provider context, where many calls to or from the same number
out-of-band capable verification service may therefore operate in one may pass through a CPS simultaneous, an out-of-band capable
of two modes: it can either pull PASSporTs from the CPS after calls verification service may therefore operate in one of two modes: it
arrive, or receive push notifications from the CPS for incoming can either pull PASSporTs from the CPS after calls arrive, or receive
calls. push notifications from the CPS for incoming calls.
If a CPS serves only one service provider, then all PASSporTs If a CPS serves only one service provider, then all PASSporTs
submitted to the CPS are made available to the OOB-VS of that 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 provider; indeed, the CPS and OOB-VS may be colocated or effectively
operated as a consolidated system. In a multi-provider environment, operated as a consolidated system. In a multi-provider environment,
the STIR credential of the terminating domain can be used by the CPS 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 determine the range of TNAuthLists for which an OOB-VS is entitled
to receive PASSporTs; this may be through a mechanism like mutual to receive PASSporTs; this may be through a mechanism like mutual
TLS, or through using the STIR credential to sign a token that is TLS, or through using the STIR credential to sign a token that is
submitted to the CPS by the retrieving OOB-VS. Note that a CPS will submitted to the CPS by the retrieving OOB-VS. Note that a multi-
need to inspect the "dest" element of a PASSporT to determine which provider CPS will need to inspect the "dest" element of a PASSporT to
OOB-VS should receive the PASSporT in this case. [TBD: Which sub/not determine which OOB-VS should receive the PASSporT.
protocol to use for the case where the CPS and OOB-VS are not
composed in a single function?]
Pulling of PASSporTs from the CPS will follow the basic REST flow [TBD: Which sub/not protocol to use for the case where the CPS and
described in [I-D.ietf-stir-oob] Section 9. In the push interface OOB-VS are not composed in a single function?]
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 Pulling of PASSporTs from the CPS will follow the basic REST flow
via its OOB-VS after having received a call in cases when the call described in [I-D.ietf-stir-oob] Section 9. Exactly how a CPS
signaling does not itself carry a STIR signature. In the push model, determines which PASSporTs an OOB-VS is eligible to receive is a
a PASSporT might be sent to the OOB-VS either before or after 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 polls the
CPS via its OOB-VS after having received a call, in those cases where
the call signaling does not itself carry a PASSporT. 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. unsigned call signaling has been received by the terminating domain.
Domains using the push model may therefore need to adopt a model Domains using the push model may therefore need to adopt a model
where call signaling is held momentarily in order to await the where the display of call verification for alerting is held
potential arrival of a PASSporT at the OOB-VS. The exact timing of momentarily in order to await the potential arrival of a PASSporT at
this, and its interaction with the substitution attack described in the OOB-VS. The exact timing of this, and its interaction with the
[I-D.ietf-stir-oob] Section 7.4, will be the covered by future substitution attack described in [I-D.ietf-stir-oob] Section 7.4,
versions of this specification. will be the covered by future versions of this specification.
7. Gateways 7. Gateways
In some deployment architectures, gateways might perform a function In some deployment architectures, gateways might perform a function
that interfaces with a CPS for the retrieval or storage of PASSporTs. 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 especially in cases when in-band STIR service providers need to
INVITEs to a gateway in front of a traditional PSTN tandem that exchange secure calls with providers that can only be reached by STIR
services a set of legacy service providers. In that environment, a out-of-band. For example, a closed network of in-band STIR providers
gateway might take a PASSporT out of in-band SIP INVITEs and store it may send SIP INVITEs to a gateway in front of a traditional PSTN
in a CPS that was established to handle requests for one or more tandem that services a set of legacy service providers. In that
legacy providers, who in turn consume those PASSporTs through an OOB- environment, a gateway might extract a PASSporT from an in-band SIP
VS to assist in robocall mitigation and similar functions. INVITE 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 The simplest way to interface a gateway performing this sort of
function for a service provider CPS system is to issue credentials to 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 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 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 the CPS acting on behalf of the legacy providers, and also to create
PASSporTs for in-band STIR conveyance from the legacy-providers to PASSporTs for in-band STIR conveyance from the legacy-providers to
terminating service providers in the closed STIR network. terminating service providers in the closed STIR network. For
example, a service provider could issue a delegate certificate
[I-D.ietf-stir-cert-delegation] for this purpose.
8. Acknowledgments 8. Acknowledgments
We would like to thank Alex Fenichel for contributions to this We would like to thank Alex Fenichel for contributions to this
specification. specification.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
TBD. It is the aim of this mechanism to provide
11. Informative References 11. Informative References
[I-D.ietf-stir-cert-delegation]
Peterson, J., "STIR Certificate Delegation", draft-ietf-
stir-cert-delegation-03 (work in progress), July 2020.
[I-D.ietf-stir-oob] [I-D.ietf-stir-oob]
Rescorla, E. and J. Peterson, "STIR Out-of-Band Rescorla, E. and J. Peterson, "STIR Out-of-Band
Architecture and Use Cases", draft-ietf-stir-oob-07 (work Architecture and Use Cases", draft-ietf-stir-oob-07 (work
in progress), March 2020. in progress), March 2020.
[I-D.ietf-stir-passport-divert] [I-D.ietf-stir-passport-divert]
Peterson, J., "PASSporT Extension for Diverted Calls", Peterson, J., "PASSporT Extension for Diverted Calls",
draft-ietf-stir-passport-divert-09 (work in progress), draft-ietf-stir-passport-divert-09 (work in progress),
July 2020. July 2020.
 End of changes. 26 change blocks. 
94 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/