Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 9888 TransUnion
Category: Standards Track June 2026
ISSN: 2070-1721
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (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.
Secure Telephone Identity Revisited（STIR）フレームワークは、パーソナル アサーション トークン（PASSporT）を帯域内でセッション開始プロトコル（SIP）要求のヘッダー内で伝送するか、または信頼当事者による取得のために PASSporT を保存するサービスを通じて帯域外で伝送する手段を定義します。この仕様は、帯域内 STIR 伝達が普遍的に利用できない場合に大規模なサービス プロバイダーをサポートするために PASSporT の帯域外伝達を使用できる方法を定義します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9888.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9888 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Service Provider Deployment Architecture for Out-of-Band STIR
4. Advertising a CPS
5. Submitting a PASSporT
6. PASSporT Retrieval
7. Gateways
8. IANA Considerations
9. Privacy Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Author's Address
The Secure Telephone Identity Revisited (STIR) [RFC8224] framework 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 [RFC8816] 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 transiting a gateway to the Public Switched Telephone Network (PSTN), or similar circumstances.
Secure Telephone Identity Revisited (STIR) [RFC8224] フレームワークは、望ましくないロボコール、スワッティング、ビッシング、ボイスメール ハッキング、および同様の攻撃の主要な要因であるなりすましを防止するために、発呼者の身元を暗号化して保証します ([RFC7340] を参照)。STIR アウトオブバンド [RFC8816] フレームワークは、PASSporT [RFC8225] オブジェクトを、SIP などのシグナリング プロトコル内で伝送するのではなく、呼配置サービス (CPS) を通じて配信できるようにします。帯域外伝送は、ネットワーク境界ポリシー、公衆交換電話網 (PSTN) へのゲートウェイを定期的に通過する通話、または同様の状況により、通話のエンドツーエンド SIP 配信が部分的または完全に利用できない場合に役立ちます。
While out-of-band STIR can be implemented as an open Internet service, it requires complex security and privacy 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, thus, who will necessarily know the parties communicating, so an alternative security architecture becomes possible. These functions may be crucial to the adoption of STIR in some environments, like legacy non-IP telephone networks, where in-band transmission of PASSporTs may not be feasible.
帯域外 STIR はオープン インターネット サービスとして実装できますが、CPS に通話を発信する当事者に関するデータを収集させずに CPS 機能を有効にするには、複雑なセキュリティおよびプライバシー対策が必要です。この仕様では、STIR が保護する通話を処理するサービス プロバイダーに代わって動作する CPS 実装について説明します。このサービス プロバイダーは通信する当事者を必然的に知っているため、代替のセキュリティ アーキテクチャが可能になります。これらの機能は、PASSporT の帯域内送信が不可能なレガシーの非 IP 電話ネットワークなど、一部の環境で STIR を採用するために重要になる場合があります。
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. That last case may include PSTN gateway or interexchange or international transit providers.
このような STIR アウトオブバンドをサポートする環境には、通信事業者、大企業、コールセンター、または多数の電話エンドポイントに代わって集約するインターネット サービスが含まれます。最後のケースには、PSTN ゲートウェイ、相互交換、または国際トランジット プロバイダーが含まれる場合があります。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The architecture in this specification assumes that every participating service provider is associated with one or more designated CPS instances. A service provider's CPS serves as a place where callers or, in some cases, gateways 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, nor does it prohibit multiple service providers from sharing a CPS provider. Moreover, a particular CPS can be a logically distributed entity compromised of several geographically distant entities that flood PASSporTs among themselves to support an anycast-like service.
この仕様のアーキテクチャでは、参加しているすべてのサービス プロバイダーが 1 つ以上の指定された CPS インスタンスに関連付けられていることを前提としています。サービス プロバイダーの CPS は、発信者、または場合によってはゲートウェイが、宛先サービス プロバイダーの加入者に電話をかけようとするときに PASSporT を預けることができる場所として機能します。発信者のドメインが帯域内 STIR をサポートしている場合、これは帯域内 STIR 通話の発信と同時に行うことができます。終端サービスプロバイダー自体が CPS を操作することも、サードパーティが宛先の代わりに CPS を操作することもできます。このモデルは、すべてのサービス プロバイダーに代わって動作するモノリシック CPS を想定していません。また、複数のサービス プロバイダーが CPS プロバイダーを共有することを禁止していません。さらに、特定の CPS は、エニーキャストのようなサービスをサポートするために相互に PASSporT をフラッディングする、地理的に離れた複数のエンティティから侵害された論理的に分散されたエンティティである可能性があります。
The process of locating a destination CPS and submitting a PASSporT naturally requires Internet connectivity to the CPS. If the CPS is deployed in the terminating service provider network, any such network connectivity could instead be leveraged by a caller to initiate a SIP session, during which in-band STIR could be used normally. Therefore, the applicability of this architecture is to those cases where, for whatever reason, SIP requests cannot reliably convey PASSporTs end-to-end, but an HTTP transaction can reliably be sent to the CPS from an out-of-band authentication service (OOB-AS). 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.
宛先 CPS を見つけて PASSporT を提出するプロセスでは、当然のことながら CPS へのインターネット接続が必要です。CPS が終端サービス プロバイダー ネットワークに展開されている場合、発信者はそのようなネットワーク接続を利用して SIP セッションを開始することができ、その間はインバンド STIR が通常どおり使用されます。したがって、このアーキテクチャが適用できるのは、何らかの理由で SIP 要求が PASSporT をエンドツーエンドで確実に伝達できないが、HTTP トランザクションは帯域外認証サービス (OOB-AS) から CPS に確実に送信できる場合です。電話プロバイダー間の IP 接続が増加するにつれて、帯域外メカニズムの必要性が少なくなることが期待されていますが、サービス プロバイダーが SIP 通話のエンドツーエンド配信が行われるかどうかを予測できない場合、帯域外メカニズムはフォールバック メカニズムとして機能する可能性があります。
If more than one CPS exists for a given deployment, there will need to be some means of discovering CPSs, either administratively or programmatically. Many service providers have bilateral agreements to peer with one another; in those environments, identifying their respective CPSs could be a simple matter of provisioning. A consortium of service providers could agree to choose from a list of available CPS providers, say. But in more pluralist environments, some mechanism is needed to discover the CPS associated with the target of a call.
特定の展開に複数の CPS が存在する場合は、管理的またはプログラム的に CPS を検出する何らかの手段が必要になります。多くのサービス プロバイダーは、相互にピア関係を築くための二国間協定を結んでいます。これらの環境では、それぞれの CPS を識別することは、プロビジョニングだけで済む可能性があります。たとえば、サービス プロバイダーのコンソーシアムは、利用可能な CPS プロバイダーのリストから選択することに同意することができます。しかし、より多元的な環境では、呼び出しのターゲットに関連付けられた CPS を検出するために何らかのメカニズムが必要になります。
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 that contains the URL of a CPS as well as any information needed to determine which 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 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.
サービスプロバイダーが選択した CPS を安全に発見できるようにするために、この仕様では CPS アドバタイズメントを定義します。事実上、CPS 広告は、CPS の URL と、どの PASSporT をその CPS に提出するかを決定するために必要な情報 (サービス プロバイダー コード (SPC) や電話番号の範囲など) を含む文書です。広告は、STIR [RFC8226] 資格情報、または特定の STIR 環境の参加者によって信頼される別の資格情報で署名できます。STIR 証明書を使用して署名する利点は、サービス プロバイダーが制御する電話ネットワーク リソースを示す「TNAuthList」値が証明書に含まれていることです。この情報を CPS アドバタイズメント内の TNAuthList 値と照合して、署名者が特定の CPS を PASSporT の適切な宛先としてアドバタイズする権限を持っているかどうかを判断できます。
The format of a service provider CPS advertisement consists of a simple JSON object containing one or more pairs of TNAuthList values pointing to the URIs of CPSs, for example:
サービス プロバイダーの CPS アドバタイズメントの形式は、CPS の URI を指す TNAuthList 値の 1 つ以上のペアを含む単純な JSON オブジェクトで構成されます。次に例を示します。
{ "0-1234":"https://cps.example.com" }
{ "0-1234":"https://cps.example.com" }
The format of this is a hyphen-separated concatenation of each [RFC8226] TNAuthList TNEntry value ("0" for SPC, "1" for telephone number range, "2" for individual telephone number) with the corresponding TNAuthList value. Note for case "1", telephone number ranges are expressed by a starting telephone number followed by a count, and the count itself; they are hyphen-separated from the TN (e.g., "1-15714341000-99"). An advertisement can contain multiple such ranges by adding more pairs. CPS URIs MUST be HTTPS URIs (Section 4.2.2 of [RFC9110]). 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; however, in more constrained environments, they MAY be only reachable over a closed network.
この形式は、各 [RFC8226] TNAuthList TNEntry 値 (SPC の場合は「0」、電話番号範囲の場合は「1」、個別の電話番号の場合は「2」) と対応する TNAuthList 値をハイフンで区切って連結したものです。ケース「1」の場合、電話番号の範囲は、開始電話番号とその後に続くカウント、およびカウント自体によって表されることに注意してください。これらは TN からハイフンで区切られています (例: "1-15714341000-99")。さらにペアを追加することで、アドバタイズメントにそのような範囲を複数含めることができます。CPS URI は HTTPS URI でなければなりません ([RFC9110] のセクション 4.2.2)。サービスプロバイダーは通常、接続を希望する可能性のあるすべての潜在的な呼び出し元を予測できないため、これらの CPS URI はパブリックに到達可能である必要があります。ただし、より制限された環境では、閉じたネットワーク経由でのみ到達可能である可能性があります。
Advertising an SPC may be inappropriate in environments where an originating domain has no ready means to determine whether a given called telephone number falls within the scope of an SPC (such as a national routing database that maps telephone numbers to SPCs). In such environments, TN-based advertisements could enable discovery instead. Also, note that PASSporTs can be used to sign communication where the "orig" and/or "dest" are not telephone numbers as such, but instead URI-based identifiers; typically, these PASSporTs would not be validated with a certificate as described in [RFC8226] and any future specification would be required to identify URI-based prefixes for CPS advertisements.
SPC のアドバタイズは、発信元ドメインに、特定の着信電話番号が SPC の範囲内にあるかどうかを判断する手段 (電話番号を SPC にマッピングする国内ルーティング データベースなど) がない環境では不適切な場合があります。このような環境では、代わりに TN ベースのアドバタイズメントによって検出が可能になる可能性があります。また、PASSporT は、「発信元」や「宛先」が電話番号そのものではなく、URI ベースの識別子である通信に署名するために使用できることにも注意してください。通常、これらの PASSporT は [RFC8226] で説明されているように証明書では検証されず、将来の仕様では CPS 広告の URI ベースのプレフィックスを識別する必要があるでしょう。
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.
CPS 広告は、既存または新しいデータベースを通じて利用可能になり、複数のサービス プロバイダーにわたって集約され、必要に応じて発信者に配信される可能性があります。これらは、DNS ルックアップなどのコール ルーティング プロセス中に検出される可能性があります。これらは、多国間ピアリング配置の参加者間で分散データベースを通じて共有できます。
An alternative to CPS advertisements that may be usable in some environments is adding a field to STIR certificates as described in [RFC8226] identifying the CPS URI issued to individual service providers. As these certificates are themselves signed by a Certification Authority (CA) and contain their own TNAuthList, the URI would be bound securely to the proper telephone network identifiers. 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.
一部の環境で使用できる CPS アドバタイズメントの代替方法は、[RFC8226] で説明されているように、個々のサービスプロバイダーに発行された CPS URI を識別するフィールドを STIR 証明書に追加することです。これらの証明書自体は認証局 (CA) によって署名されており、独自の TNAuthList が含まれているため、URI は適切な電話ネットワーク ID に安全にバインドされます。STIR は、これらの資格情報を信頼する信頼当事者のコミュニティを想定しているため、この方法はおそらく、CPS が PASSporT の送信と取得を承認できるようにするために必要な信頼モデルを最もよく反映しています。
Submitting a PASSporT to a CPS as specified in the STIR out-of-band framework [RFC8816] requires security measures that are intended to prevent the CPS from learning the identity of the caller (or callee) to the degree possible. However, in this service provider case, 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 (see Section 10 for potential data minimization concerns). Therefore, the service provider out-of-band framework does not attempt to conceal the identity of the originating or terminating party from the CPS.
STIR 帯域外フレームワーク [RFC8816] で指定されているように PASSporT を CPS に送信するには、CPS が発信者 (または着信者) の ID を可能な限り学習しないようにすることを目的としたセキュリティ対策が必要です。ただし、このサービス プロバイダーの場合、CPS は着信者のサービス プロバイダー (またはその代わりに動作するエンティティ) によって運用され、そのため、PASSporT に表示される情報は、着信側がいずれにせよ受信する通話シグナリングと重複しています (潜在的なデータ最小化の問題についてはセクション 10 を参照)。したがって、サービス プロバイダーの帯域外フレームワークは、発信側または着信側の ID を CPS から隠そうとしません。
An 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 SHOULD authenticate itself to the CPS via mutual TLS (see [RFC9325]) 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. Furthermore, the 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.
OOB-AS は、ターゲット CPS との安全な接続を形成します。これは、通話の発信時に発生する場合もあれば、このインターフェイス上で大量のトラフィックが送信される場合に永続的な接続が発生する場合もあります。OOB-AS は、呼び出しの署名に使用するものと同じ STIR 資格情報 [RFC8226] を使用して、相互 TLS ([RFC9325] を参照) 経由で CPS に対して自身を認証する必要があります (SHOULD)。これは、よりオープンな OOB 実装が直面する可能性のあるフラッディングのリスクを軽減するのに役立ちます。さらに、相互 TLS の使用により、攻撃者がキャプチャされた PASSporT を CPS に再実行することを防ぎます。CPS は、特定の OOB-AS からの呼び出しを受け入れるかどうか、およびどのくらいのボリュームで呼び出しを受け入れるかについて独自のポリシーを決定します。
A CPS can use this mechanism to 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 for more on their behavior.
CPS は、このメカニズムを使用して、すでに STIR 資格情報を保持しているサービス プロバイダーに PASSporT を CPS に送信することを許可できますが、PASSporT を提出したいゲートウェイ プロバイダーやトランジット プロバイダーなど、STIR 資格情報を保持していないエンティティには代替メカニズムが必要になります。彼らの行動の詳細については、セクション 7 を参照してください。
Service provider out-of-band PASSporTs do not need to be encrypted for storage at the CPS, although the use of TLS to prevent eavesdropping on the connection between the CPS and OOB-ASs is REQUIRED. PASSporTs will typically 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 MUST implement a Representational State Transfer (REST) interface to submit PASSporTs to the CPS as described in Section 9 of [RFC8816]. PASSporTs persist at the CPS for as long as is required for them to be retrieved (see Section 6) but, in any event, for no longer than the freshness interval of the PASSporT itself (a maximum of sixty seconds).
サービス プロバイダーの帯域外 PASSporT は、CPS での保管のために暗号化する必要はありませんが、CPS と OOB-AS の間の接続での盗聴を防ぐために TLS の使用が必須です。PASSporT は通常、AS によって作成されたときに CPS に送信されます。PASSporT が SIP リクエスト内のインバンド トランジットにも使用されている場合は、発信元ドメインの裁量で、SIP リクエストの送信前または送信後に PASSporT を CPS に送信できます。OOB-AS は、[RFC8816] のセクション 9 で説明されているように、PASSporT を CPS に送信するために Representational State Transfer (REST) インターフェースを実装しなければなりません (MUST)。PASSporT は、取得に必要な期間 (セクション 6 を参照) CPS に存続しますが、いずれの場合も PASSporT 自体の更新間隔 (最大 60 秒) を超えないようにしてください。
The STIR out-of-band framework [RFC8816] proposes two means by which called parties can acquire PASSporTs out-of-band: through a retrieval interface or a subscription interface. In the service provider context, where many calls to or from the same number may pass through a CPS simultaneously, an out-of-band-capable verification service (OOB-VS) 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.
STIR アウトオブバンド フレームワーク [RFC8816] は、着信側がアウトオブバンドで PASSporT を取得できる 2 つの手段、つまり、取得インターフェイスまたはサブスクリプション インターフェイスを提案しています。サービス プロバイダーのコンテキストでは、同じ番号への、または同じ番号からの多数の通話が同時に CPS を通過する可能性があるため、帯域外対応検証サービス (OOB-VS) は 2 つのモードのいずれかで動作します。通話の到着後に CPS から PASSporT を取得するか、着信通話について CPS からプッシュ通知を受信します。
CPS implementations MUST support pulling of the PASSporTs via the REST flow described in Section 9 of [RFC8816]. In the pull model, a terminating service provider polls the CPS via its OOB-VS after having received a call for which the call signaling does not itself carry a PASSporT. Exactly how a CPS determines which PASSporTs an OOB-VS is eligible to receive over this interface is a matter of local policy. 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; this may be through a mechanism like mutual TLS or through the use of the STIR credential to sign a token that is submitted to the CPS by the retrieving OOB-VS. Note that a multi-provider CPS will need to inspect the "dest" element of a PASSporT to determine which OOB-VS should receive the PASSporT.
CPS 実装は、[RFC8816] のセクション 9 で説明されている REST フローを介した PASSporT のプルをサポートしなければなりません (MUST)。プル モデルでは、着信サービス プロバイダーは、コール シグナリング自体が PASSporT を伝送しないコールを受信した後、OOB-VS を介して CPS をポーリングします。OOB-VS がこのインターフェイス経由でどの PASSporT を受信できるかを CPS が正確にどのように判断するかは、ローカル ポリシーの問題です。CPS が 1 つのサービス プロバイダーのみにサービスを提供する場合、CPS に送信されたすべての PASSporT がそのプロバイダーの OOB-VS で利用可能になります。実際、CPS と OOB-VS は同じ場所に配置することも、統合システムとして効果的に運用することもできます。マルチプロバイダー環境では、終端ドメインの STIR 資格情報を CPS が使用して、OOB-VS が PASSporT を受信する資格のある TNAuthList の範囲を決定できます。これは、相互 TLS などのメカニズムを通じて、または OOB-VS の取得によって CPS に送信されるトークンに署名するための STIR 資格情報の使用を通じて行われる場合があります。マルチプロバイダー CPS は、PASSporT の「dest」要素を検査して、どの OOB-VS が PASSporT を受信するかを決定する必要があることに注意してください。
In a push model, an OOB-VS could, for example, subscribe to a range of telephone numbers or a list of SPCs, which will be directed to that OOB-VS by the CPS (provided the OOB-VS is authorized to receive them by the CPS). PASSporT might be sent to the OOB-VS either before or after unsigned call signaling has been received by the terminating domain. In either model, the terminating side may need to delay rendering a call verification indicator when alerting, 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 Section 7.4 of [RFC8816], is left for future work.
プッシュ モデルでは、OOB-VS は、たとえば、ある範囲の電話番号や SPC のリストに登録でき、それらは CPS によってその OOB-VS に送信されます (OOB-VS が CPS によってそれらを受信する権限を与えられている場合)。PASSporT は、未署名のコール シグナリングが終端ドメインで受信される前または後のいずれかに OOB-VS に送信されることがあります。どちらのモデルでも、着信側は、OOB-VS に PASSporT が到着する可能性を待つために、警告を発するときに通話検証インジケーターのレンダリングを遅らせる必要がある場合があります。この正確なタイミングと、[RFC8816] のセクション 7.4 で説明されている置換攻撃との相互作用は、将来の作業に残されています。
In some deployment architectures, gateways might perform a function that interfaces with a CPS for the retrieval or storage of PASSporTs, especially in cases when in-band STIR service providers need to exchange secure calls with providers that can only be reached by STIR out-of-band. 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 extract a PASSporT from an in-band SIP 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.
一部の導入アーキテクチャでは、特にインバンド STIR サービス プロバイダーが、帯域外 STIR によってのみ到達できるプロバイダーと安全なコールを交換する必要がある場合に、ゲートウェイが PASSporT の取得または保存のために CPS とインターフェースする機能を実行する場合があります。たとえば、インバンド STIR プロバイダーの閉域ネットワークは、一連のレガシー サービス プロバイダーにサービスを提供する従来の PSTN タンデムの前にあるゲートウェイに SIP INVITE を送信する場合があります。その環境では、ゲートウェイがインバンド SIP INVITE から PASSporT を抽出し、1 つ以上のレガシー プロバイダーへのリクエストを処理するために確立された CPS に保存する可能性があります。次に、レガシー プロバイダーは、ロボコールの軽減や同様の機能を支援するために、OOB-VS を通じてそれらの PASSporT を消費します。
The simplest way to implement 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. For example, a service provider could issue a delegate certificate [RFC9060] for this purpose.
サービス プロバイダーの CPS システムに対してこの種の機能を実行するゲートウェイを実装する最も簡単な方法は、ゲートウェイがサポートするレガシー サービス プロバイダーに代わって動作できるようにする資格情報をゲートウェイに発行することです。これにより、ゲートウェイはレガシー プロバイダーに代わって動作する CPS に PASSporT を追加することと、レガシー プロバイダーから閉域 STIR ネットワーク内の終端サービス プロバイダーへのインバンド STIR 伝達用の PASSporT を作成することができます。たとえば、サービスプロバイダーは、この目的のために委任証明書 [RFC9060] を発行できます。
This document has no IANA actions.
この文書には IANA のアクションはありません。
The analysis of out-of-band STIR in the Privacy Considerations section of [RFC8816] differs considerably from this document. Per Section 1, this specification was motivated in part by choosing a different privacy architecture than [RFC8816], one in which the CPS is operated by a service provider who is a party to the call itself and, thus, would independently have access to the call metadata captured in a PASSporT.
[RFC8816] のプライバシーに関する考慮事項セクションの帯域外 STIR の分析は、この文書とは大きく異なります。セクション 1 によれば、この仕様は、[RFC8816] とは異なるプライバシー アーキテクチャを選択することによって部分的に動機付けられました。このアーキテクチャでは、CPS は通話自体の当事者であるサービス プロバイダーによって運用され、したがって PASSporT でキャプチャされた通話メタデータに独立してアクセスできるようになります。
That said, in cases where a third-party service operates the verification service function on behalf of a carrier, that third-party service would indeed be privy to this metadata. It is a fairly common situation for third-party services to receive this sort of metadata to perform tasks related to billing, security, number translation, and so on; existing data governance agreements could be readily applied to the out-of-band STIR use case.
とはいえ、サードパーティ サービスが通信事業者に代わって検証サービス機能を運用している場合、そのサードパーティ サービスは確かにこのメタデータを知ることになります。サードパーティ サービスが、請求、セキュリティ、番号変換などに関連するタスクを実行するためにこの種のメタデータを受信することは、非常に一般的な状況です。既存のデータ ガバナンス協定は、帯域外 STIR の使用例に容易に適用できます。
Finally, note that PASSporTs are extensible tokens, and it is conceivable that they might contain data that is not otherwise carried in SIP signaling or that would ordinarily be considered a component of call metadata. Any such extensions might have specific interactions with the privacy of both in-band and out-of-band STIR that their specifications would need to elaborate.
最後に、PASSporT は拡張可能なトークンであり、SIP シグナリングで伝送されないデータや、通常は通話メタデータのコンポーネントとみなされるデータが含まれる可能性があることに注意してください。このような拡張機能には、帯域内および帯域外の両方の STIR のプライバシーとの特定の相互作用がある可能性があり、その仕様を詳しく説明する必要があります。
The Security Considerations section of [RFC8816] applies to this document, including concerns about potential denial-of-service vectors and traffic analysis. However, that specification's model focused a great deal on the privacy implications of uploading PASSporTs to a third-party web service. This document mitigates those concerns by making the CPS one of the parties to call setup (or an entity contractually acting on their behalf). That said, any architecture in which PASSporTs are shared with a federated or centralized CPS raises potential concerns about data collection [RFC7258]. Moreover, in a PASSporT, any additional information that is not strictly redundant with the contents of a SIP request increases data collection concerns; PASSporTs as defined in [RFC8225] only contain information redundant with the SIP request. Existing and future extensions (e.g., the "origid" field described in [RFC8588]) might leak further information.
[RFC8816] のセキュリティに関する考慮事項セクションがこの文書に適用され、潜在的なサービス拒否ベクトルとトラフィック分析に関する懸念が含まれます。ただし、その仕様のモデルは、PASSporT をサードパーティの Web サービスにアップロードすることによるプライバシーへの影響に重点を置いています。この文書では、CPS を通話セットアップの当事者 (または、契約上その代理を務める団体) の 1 つとすることで、これらの懸念を軽減します。とはいえ、PASSporT が連合または集中型 CPS と共有されるアーキテクチャでは、データ収集に関する潜在的な懸念が生じます [RFC7258]。さらに、PASSporT では、SIP リクエストの内容と厳密には冗長ではない追加情報により、データ収集の懸念が増大します。[RFC8225] で定義されている PASSporT には、SIP リクエストと重複する情報のみが含まれます。既存および将来の拡張機能 ([RFC8588] で説明されている "origid" フィールドなど) により、さらなる情報が漏洩する可能性があります。
Unlike [RFC8816], this document proposes the use of STIR certificates to authenticate transactions with a CPS as well as signatures for CPS advertisements. This presumes an environment where STIR certificates are issued by trust anchors that are already trusted by the CPS, potentially to gateways and similar services. Common STIR deployments use SPCs instead of telephone number ranges to identify service providers today; determining whether a given SPC entitles a service provider to access PASSporTs for a given telephone number is not trivial, but is a necessary component of this CPS architecture. Otherwise, if anyone with a STIR certificate were able to publish or access PASSporTs for any telephone number, this could lead to an undesirable environment where effectively anyone with a STIR certificate could acquire PASSporTs for calls in progress to any service provider.
[RFC8816] とは異なり、この文書は CPS とのトランザクションおよび CPS 広告の署名を認証するために STIR 証明書を使用することを提案しています。これは、CPS によってすでに信頼されているトラスト アンカーによって STIR 証明書が発行され、場合によってはゲートウェイや同様のサービスに対して発行される環境を前提としています。現在、一般的な STIR 展開では、電話番号範囲の代わりに SPC を使用してサービス プロバイダーを識別しています。特定の SPC がサービス プロバイダーに特定の電話番号の PASSporT にアクセスする権利を与えるかどうかを判断することは簡単ではありませんが、この CPS アーキテクチャの必要なコンポーネントです。そうしないと、STIR 証明書を持っている人が任意の電話番号の PASSporT を公開またはアクセスできる場合、STIR 証明書を持っている人は事実上、任意のサービス プロバイダーへの通話中の PASSporT を取得できるという望ましくない環境が生じる可能性があります。
[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>.
[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>.
[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases",
RFC 8816, DOI 10.17487/RFC8816, February 2021,
<https://www.rfc-editor.org/info/rfc8816>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[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>.
[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
(PaSSporT) Extension for Signature-based Handling of
Asserted information using toKENs (SHAKEN)", RFC 8588,
DOI 10.17487/RFC8588, May 2019,
<https://www.rfc-editor.org/info/rfc8588>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>.
Thank you to Alex Fenichel for contributing to this specification.
この仕様に貢献してくれた Alex Fenichel に感謝します。
Jon Peterson
TransUnion
Email: jon.peterson@transunion.com