[要約] RFC 8816は、STIRのアウトオブバンドアーキテクチャと使用事例に関する規格です。このRFCの目的は、電話番号の偽装を防ぎ、通信の信頼性を向上させることです。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8816 Mozilla
Category: Informational J. Peterson
ISSN: 2070-1721 Neustar
February 2021
Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases
セキュア・テレフォン・アイデンティティ再訪（STIR）の帯域外アーキテクチャと使用例
Abstract
概要
The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.
Personal Assertion Token(PASSporT)形式は、発信者の身元を暗号化して証明するために、 SIPを含むシグナリングプロトコルによって運ばれることができるトークンを定義する。しかしながら、すべての電話呼がインターネットシグナリングプロトコルを使用するわけではな く、一部の呼はシグナリングパスの一部だけにそれらを使用し、一部の呼は SIPヘッダーフィールドをエンドツーエンドで確実に配信できない。このドキュメントでは、シグナリングパスの外でPASSporTオブジェクトの配送を必要とする ユースケースについて述べ、この機能を提供するためのアーキテクチャとセマンティクスを定義する。
Status of This Memo
本メモの状況
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準化トラックの仕様ではなく、情報提供を目的として公開されている。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネット技術タスクフォース(IETF)の成果物である。これは IETF コミュニティのコンセンサスを表している。この文書はパブリックレビューを受け、インターネットエンジニアリング運営グループ(IESG)によって出版が承認されている。IESGによって承認されたすべての文書が、どのレベルのインターネット標準の候補でもあるわけではない。
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/rfc8816.
この文書の現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8816 で入手することができる。
Copyright Notice
著作権について
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文書は、本文書の発行日に有効なBCP 78およびIETF信託のIETF文書に関する法的規定(https://trustee.ietf.org/license-info)の対象となります。これらの文書には、本文書に関するあなたの権利と制限事項が記載されているので、注意して確認してください。この文書から抽出されたコードコンポーネントは、トラストの法的規定の第4.e項に記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供されています。
Table of Contents
目次
1. Introduction
2. Terminology
3. Operating Environments
4. Dataflows
5. Use Cases
5.1. Case 1: VoIP to PSTN Call
5.2. Case 2: Two Smart PSTN Endpoints
5.3. Case 3: PSTN to VoIP Call
5.4. Case 4: Gateway Out-of-Band
5.5. Case 5: Enterprise Call Center
6. Storing and Retrieving PASSporTs
6.1. Storage
6.2. Retrieval
7. Solution Architecture
7.1. Credentials and Phone Numbers
7.2. Call Flow
7.3. Security Analysis
7.4. Substitution Attacks
7.5. Rate Control for CPS Storage
8. Authentication and Verification Service Behavior for
Out-of-Band
8.1. Authentication Service (AS)
8.2. Verification Service (VS)
8.3. Gateway Placement Services
9. Example HTTPS Interface to the CPS
10. CPS Discovery
11. Encryption Key Lookup
12. IANA Considerations
13. Privacy Considerations
14. Security Considerations
15. Informative References
Acknowledgments
Authors' Addresses
The STIR problem statement [RFC7340] describes widespread problems enabled by impersonation in the telephone network, including illegal robocalling, voicemail hacking, and swatting. As telephone services are increasingly migrating onto the Internet, and using Voice over IP (VoIP) protocols such as SIP [RFC3261], it is necessary for these protocols to support stronger identity mechanisms to prevent impersonation. For example, [RFC8224] defines a SIP Identity header field capable of carrying PASSporT objects [RFC8225] in SIP as a means to cryptographically attest that the originator of a telephone call is authorized to use the calling party number (or, for native SIP cases, SIP URI) associated with the originator of the call.
STIRの問題文(RFC7340)は、違法なロボコール、ボイスメールハッキング、ス ワッティングなど、電話ネットワークにおけるなりすましによって可能になる広範な問題を記述しています。電話サービスのインターネットへの移行が進み、SIP [RFC3261]のようなVoice over IP (VoIP)プロトコルを使用するようになると、これらのプロトコルでは、なりすましを防ぐためのより強力なIDメカニズムをサポートすることが必要になります。たとえば、SIPのPASSporTオブジェクト[RFC8225]を運ぶことができるSIP Identityヘッダーフィールドを定義している[RFC8224]。これは、電話の発信者が、呼の発信者に関連付けられた発信者番号(SIPネイティブの場合は SIP URI)の使用を許可されていることを暗号化して証明する手段である。
Not all telephone calls use SIP today, however, and even those that do use SIP do not always carry SIP signaling end-to-end. Calls from telephone numbers still routinely traverse the Public Switched Telephone Network (PSTN) at some point. Broadly, calls fall into one of three categories:
しかし、今日、すべての電話がSIPを使用しているわけではなく、SIPを使用している場合でも、常にエンドツーエンドでSIPシグナリングが行われているわけではありません。電話番号からの通話は、今でもどこかの時点で公衆交換電話網(PSTN)を日常的に通過します。一般的に、呼は3つのカテゴリのうちの1つに分類される。
1. One or both of the endpoints is actually a PSTN endpoint.
1. エンドポイントの一方または両方が実際に PSTN エンドポイントである。
2. Both of the endpoints are non-PSTN (SIP, Jingle, etc.) but the call transits the PSTN at some point.
2. エンドポイントの両方が非 PSTN (SIP、Jingle など) であるが、呼がどこかの時点で PSTN を通過している。
3. Non-PSTN calls that do not transit the PSTN at all (such as native SIP end-to-end calls).
3. PSTNを全く通過しない非PSTN呼(ネイティブSIPエンドツーエンド呼など)。
The first two categories represent the majority of telephone calls associated with problems like illegal robocalling: many robocalls today originate on the Internet but terminate at PSTN endpoints. However, the core network elements that operate the PSTN are legacy devices that are unlikely to be upgradable at this point to support an in-band authentication system. As such, those devices largely cannot be modified to pass signatures originating on the Internet -- or indeed any in-band signaling data -- intact. Even if fields for tunneling arbitrary data can be found in traditional PSTN signaling, in some cases legacy elements would strip the signatures from those fields; in others, they might damage them to the point where they cannot be verified. For those first two categories above, any in-band authentication scheme does not seem practical in the current environment.
最初の 2 つのカテゴリは、違法なロボコールなどの問題に関連した電話の大部分を表しています。今日、多くのロボコールはインターネットから発信され、PSTN エンドポイントで終了しています。しかし、PSTN を運用するコア・ネットワーク・エレメントは、バンド内認証システムをサポートするために、現時点ではアップグレード可能なレガシー・デバイスではありません。そのため、これらのデバイスは、インターネット上で生成されたシグネチャや、実際にはあらゆるインバンドシグナリングデータをそのまま渡すように変更することはほとんどできません。任意のデータをトンネリングするためのフィールドが従来の PSTN シグナリングにあったとしても、場合によっては、レガシー要素がこれらのフィールドから署名を取り除くことになり、また別の場合には、検証できないほどに損傷する可能性があります。上記の最初の2つのカテゴリについては、どのようなインバンド認証スキームも、現在の環境では実用的ではないと思われます。
While the core network of the PSTN remains fixed, the endpoints of the telephone network are becoming increasingly programmable and sophisticated. Landline "plain old telephone service" deployments, especially in the developed world, are shrinking, and increasingly being replaced by three classes of intelligent devices: smart phones, IP Private Branch Exchanges (PBXs), and terminal adapters. All three are general purpose computers, and typically all three have Internet access as well as access to the PSTN; they may be used for residential, mobile, or enterprise telephone services. Additionally, various kinds of gateways increasingly front for deployments of legacy PBX and PSTN switches. All of this provides a potential avenue for building an authentication system that implements stronger identity while leaving PSTN systems intact.
PSTN のコアネットワークは固定されたままですが、電話ネットワークのエンドポイントはますますプログラマブルで洗練されてきています。特に先進国では、固定電話の「昔ながらの電話サービス」の展開は縮小しており、スマートフォン、IP 内線交換機（PBX）、端末アダプタの 3 つのクラスのインテリジェントデバイスに取って代わられつつあります。これら 3 つはすべて汎用コンピュータであり、一般的には 3 つともインターネット・アクセスと PSTN へのアクセスを備えています。さらに、さまざまな種類のゲートウェイは、レガシーPBXやPSTNスイッチの展開のために、ますます前面に出てきています。これらすべてが、PSTN システムをそのままにしたまま、より強力な ID を実装する認証システムを構築するための潜在的な手段を提供しています。
This capability also provides an ideal transitional technology while in-band STIR adoption is ramping up. It permits early adopters to use the technology even when intervening network elements are not yet STIR-aware, and through various kinds of gateways, it may allow providers with a significant PSTN investment to still secure their calls with STIR.
この機能は、インバンドSTIRの採用が加速している間の理想的な移行期の技術でもあります。これは、介入するネットワーク要素がまだ STIR を認識していない場合でも、早期採用者が技術を使用することを可能にし、様々な種類のゲートウェイを通じて、多額の PSTN 投資を行っているプロバイダが STIR で通話を安全にすることを可能にするかもしれません。
The techniques described in this document therefore build on the PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a way that a PASSporT object created in the originating network of a call can reach the terminating network even when it cannot be carried end-to-end in-band in the call signaling. This relies on a new service defined in this document called a Call Placement Service (CPS) that permits the PASSporT object to be stored during call processing and retrieved for verification purposes.
したがって、このドキュメントで述べられている技術は、PASSporT [RFC8225]のメカニズムと[RFC8224]の作業を基にして、呼の発信ネットワークで作成されたPASSporTオブジェクトが、呼のシグナリングで エンドツーエンドでインバンドで運ばれない場合でも、終端ネットワークに到達することができる方法を記述する。これは、PASSporTオブジェクトが呼処理中に保存され、検証目的のために検索されることを可能にする Call Placement Service (CPS)と呼ばれる、このドキュメントで定義された新しいサービスに依存している。
Potential implementors should note that this document merely defines the operating environments in which this out-of-band STIR mechanism is intended to operate. It provides use cases, gives a broad description of the components, and a potential solution architecture. Various environments may have their own security requirements: a public deployment of out-of-band STIR faces far greater challenges than a constrained intra-network deployment. To flesh out the storage and retrieval of PASSporTs in the CPS within this context, this document includes a strawman protocol suitable for that purpose. Deploying this framework in any given environment would require additional specification outside the scope of this document.
潜在的な実装者は、このドキュメントは、この帯域外STIRメカニズムが動作することを意図した動作環境を 定義しているに過ぎないことに注意するべきである。本文書は、ユースケースを提供し、コンポーネントの大まかな説明、および潜在的なソリューション・アーキテ クチャを示しています。様々な環境には、独自のセキュリティ要件があるかもしれません。帯域外 STIR の公開展開は、制約のあるネットワーク内展開よりもはるかに大きな課題に直面します。このコンテキスト内での CPS での PASSporT の保存と検索を詳細にするために、このドキュメントにはその目的に適したストローマン・プロトコルが含まれています。任意の環境でこのフレームワークを展開するには、このドキュメントの範囲外の追加仕様が必要になります。
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]に記述されているように解釈されるべきである。
This section describes the environments in which the proposed out-of-band STIR mechanism is intended to operate. In the simplest setting, Alice calls Bob, and her call is routed through some set of gateways and/or the PSTN that do not support end-to-end delivery of STIR. Both Alice and Bob have smart devices that can access the Internet (perhaps enterprise devices, or even end-user ones), but they do not have a clear telephone signaling connection between them: Alice cannot inject any data into signaling that Bob can read, with the exception of the asserted destination and origination E.164 numbers. The calling party number might originate from her own device or from the network. These numbers are effectively the only data that can be used for coordination between the endpoints.
このセクションでは、提案された帯域外 STIR メカニズムが動作することを意図した環境について説明します。最も単純な設定では、アリスがボブに電話をかけ、彼女の電話は STIR のエンドツーエンド配信をサポートしていないゲートウェイや PSTN を経由してルーティングされます。アリスとボブは、インターネットにアクセスできるスマートデバイス（おそらく企業のデバイス、あるいはエンドユーザーのデバイス）を持っていますが、二人の間には明確な電話シグナリング接続がありません。アリスは、アサートされた宛先番号と発信元のE.164番号を除いて、ボブが読み取ることのできるシグナリングにデータを注入することはできない。発信側の番号は、彼女自身のデバイスから発信されるかもしれないし、 ネットワークから発信されるかもしれない。これらの番号は、事実上、エンドポイント間の調整に使用できる唯一のデータである。
+---------+
/ \
+--- +---+
+----------+ / \ +----------+
| | | Gateways | | |
| Alice |<----->| and/or |<----->| Bob |
| (caller) | | PSTN | | (callee) |
+----------+ \ / +----------+
+--- +---+
\ /
+---------+
In a more complicated setting, Alice and/or Bob may not have a smart or programmable device, but instead just a traditional telephone. However, one or both of them are behind a STIR-aware gateway that can participate in out-of-band coordination, as shown below:
より複雑な設定では、アリスおよび／またはボブは、スマートデバイスやプログラマブルデバイスを持っておらず、代わりに従来の電話機だけを持っているかもしれません。しかし、以下に示すように、帯域外調整に参加することができる STIR 対応ゲートウェイの背後には、それらのうちの 1 つまたは両方があります。
+---------+
/ \
+--- +---+
+----------+ +--+ / \ +--+ +----------+
| | | | | Gateways | | | | |
| Alice |<-|GW|->| and/or |<-|GW|->| Bob |
| (caller) | | | | PSTN | | | | (callee) |
+----------+ +--+ \ / +--+ +----------+
+--- +---+
\ /
+---------+
In such a case, Alice might have an analog (e.g., PSTN) connection to her gateway or switch that is responsible for her identity. Similarly, the gateway would verify Alice's identity, generate the right calling party number information, and provide that number to Bob using ordinary Plain Old Telephone Service (POTS) mechanisms.
このような場合、アリスは、彼女のアイデンティティに責任を持つゲートウェイまたはスイッチへのアナログ(例えば、PSTN)接続を持つかもしれません。同様に、ゲートウェイはアリスの身元を確認し、正しい発信者番号情報を生成し、通常のPOTS(Plain Old Telephone Service)メカニズムを使用してその番号をボブに提供します。
Because in these operating environments, endpoints cannot pass cryptographic information to one another directly through signaling, any solution must involve some rendezvous mechanism to allow endpoints to communicate. We call this rendezvous service a Call Placement Service (CPS), a service where a record of call placement, in this case a PASSporT, can be stored for future retrieval. In principle, this service could communicate any information, but minimally we expect it to include a full-form PASSporT that attests the caller, callee, and the time of the call. The callee can use the existence of a PASSporT for a given incoming call as rough validation of the asserted origin of that call. (See Section 11 for limitations of this design.)
これらの動作環境では、エンドポイントはシグナリングを介してお互いに直接暗号情報を渡すことができないため、どのようなソリューションでも、エンドポイントが通信できるようにするために、何らかのランデブーメカニズムを含まなければなりません。このランデブー・サービスをコール・プレースメント・サービス(CPS)と呼んでいます。このサービスは、コール・プレースメントの記録(この場合はPASSporT)を将来の検索のために保存することができるサービスです。原則として、このサービスはあらゆる情報を通信することができますが、最低限、発呼者、着呼者、通話時間を証明するフルフォームのPASSporTを含むことを期待しています。着呼側は、その呼のアサートされた発信元の大まかな検証として、与えられた 着信呼のためのPASSporTの存在を使用できる。(この設計の制限についてはセクション11を参照のこと)。
This architecture does not mandate that any particular sort of entity operate a CPS or mandate any means to discover a CPS. A CPS could be run internally within a network or made publicly available. One or more CPSes could be run by a carrier, as repositories for PASSporTs for calls sent to its customers, or a CPS could be built into an enterprise PBX or even a smartphone. To the degree possible, it is specified here generically as an idea that may have applicability to a variety of STIR deployments.
このアーキテクチャは、特定の種類のエンティティがCPSを操作することを義務づけたり、 CPSを発見する手段を義務づけたりするものではない。CPSは、ネットワーク内で内部的に実行されてもよいし、公開されてもよい。1つまたは複数のCPSは、通信事業者によって、その顧客に送信されたコールのためのPASSporTのリポジトリとして実行されるか、またはCPSは、企業のPBXやスマートフォンに組み込まれる可能性があります。可能な限り、それは様々なSTIRの展開に適用可能なアイデアとしてここで一般的に規定されています。
There are roughly two plausible dataflow architectures for the CPS:
CPS のデータフロー・アーキテクチャには、大まかに 2 つの可能性があります。
1. The callee registers with the CPS. When the caller wishes to place a call to the callee, it sends the PASSporT to the CPS, which immediately forwards it to the callee.
1. 着呼側はCPSに登録する。発呼側が着呼側に電話をかけたい場合は、CPSにPASSporTを送信し、CPSは直ちに着呼側に転送します。
2. The caller stores the PASSporT with the CPS at the time of call placement. When the callee receives the call, it contacts the CPS and retrieves the PASSporT.
2. 発信者は、発呼時にPASSporTをCPSに保存する。着呼側は呼を受信すると、CPSに連絡してPASSporTを取得します。
While the first architecture is roughly isomorphic to current VoIP protocols, it shares their drawbacks. Specifically, the callee must maintain a full-time connection to the CPS to serve as a notification channel. This comes with the usual networking costs to the callee and is especially problematic for mobile endpoints. Indeed, if the endpoints had the capabilities to implement such an architecture, they could surely just use SIP or some other protocol to set up a secure session; even if the media were going through the traditional PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we focus on the second architecture in which the PSTN incoming call serves as the notification channel, and the callee can then contact the CPS to retrieve the PASSporT. In specialized environments, for example, a call center that receives a large volume of incoming calls that originated in the PSTN, the notification channel approach might be viable.
最初のアーキテクチャは現在のVoIPプロトコルとほぼ同形ですが、欠点も共有しています。具体的には、着呼側は通知チャネルとして機能するためにCPSとのフルタイム接続を維持しなければなりません。これは着呼側には通常のネットワーキング・コストがかかり、特にモバイル・エンドポイントにとっては問題となる。実際、もしエンドポイントがそのようなアーキテクチャを実装する能力を持っていたならば、安全なセッションをセッ トアップするためにSIPや他のプロトコルを使用することができるはずである。メディアが従来の PSTNを経由していたとしても、「シャドウ」SIPセッションはPASSporTを伝えることができる。したがって、我々は、PSTNの着信呼が通知チャネルとして機能し、着呼側がPASSporTを取得するためにCPSに連絡することができるという第2のアーキテクチャに焦点を当てます。例えば、PSTNで発信された大量の着信を受信するコールセンターのような特殊な環境では、通知チャネルのアプローチは実行可能かもしれません。
The following are the motivating use cases for this mechanism. Bear in mind that, just as in [RFC8224], there may be multiple Identity header fields in a single SIP INVITE, so there may be multiple PASSporTs in this out-of-band mechanism associated with a single call. For example, a SIP user agent might create a PASSporT for a call with an end-user credential, and as the call exits the originating administrative domain, the network authentication service might create its own PASSporT for the same call. As such, these use cases may overlap in the processing of a single call.
以下は、このメカニズムの動機付けとなるユースケースである。RFC8224]のように、1つのSIP INVITEには複数のIdentityヘッダーフィールドが存在する可能性があるため、1つの呼に関連するこの帯 域外メカニズムには複数のPASSporTが存在する可能性があることに留意すること。たとえば、SIPユーザーエージェントは、エンドユーザーのクレデンシャルを使用して呼のPASSporTを 作成するかもしれない。このように、これらのユースケースは、1つの呼の処理で重複する可能性がある。
A call originates in a SIP environment in a STIR-aware administrative domain. The local authentication service for that administrative domain creates a PASSporT that is carried in band in the call per [RFC8224]. The call is routed out of the originating administrative domain and reaches a gateway to the PSTN. Eventually, the call will terminate on a mobile smartphone that supports this out-of-band mechanism.
呼は、STIRを意識した管理ドメインのSIP環境で発呼する。その管理ドメインのローカル認証サービスは、[RFC8224]に従って、呼のバンド内で 運ばれるPASSporTを作成する。呼は発信元の管理ドメインからルーティングされ、PSTNへのゲートウェイに到達する。最終的に、呼は、この帯域外メカニズムをサポートするモバイルスマートフォンで終了する。
In this use case, the originating authentication service can store the PASSporT with the appropriate CPS (per the practices of Section 10) for the target telephone number as a fallback in case SIP signaling will not reach end-to-end. When the destination mobile smartphone receives the call over the PSTN, it consults the CPS and discovers a PASSporT from the originating telephone number waiting for it. It uses this PASSporT to verify the calling party number.
このユースケースでは、発信元の認証サービスは、SIPシグナリングがエンドツーエンドに到達しない場合のフォールバックとして、ターゲットの電話番号のための適切なCPS(セクション10のプラクティスに従った)を持つPASSporTを格納することができる。宛先のモバイル・スマートフォンがＰＳＴＮ上で通話を受信すると、ＣＰＳを参照し、それを待っている発信元の電話番号からPASSporTを発見する。このPASSporTを使用して発信者番号を確認する。
A call originates with an enterprise PBX that has both Internet access and a built-in gateway to the PSTN, which communicates through traditional telephone signaling protocols. The PBX immediately routes the call to the PSTN, but before it does, it provisions a PASSporT on the CPS associated with the target telephone number.
呼び出しは、インターネットアクセスとPSTNの両方のゲートウェイを持つEnterprise PBXで発信され、これは従来の電話シグナリングプロトコルを通じて通信します。PBXは直ちに呼び出しをPSTNにルーティングしますが、そうする前に、ターゲットの電話番号に関連付けられているCPS上のパスポートを規定しています。
After normal PSTN routing, the call lands on a smart mobile handset that supports the STIR out-of-band mechanism. It queries the appropriate CPS over the Internet to determine if a call has been placed to it by a STIR-aware device. It finds the PASSporT provisioned by the enterprise PBX and uses it to verify the calling party number.
通常のPSTNルーティングの後、コールは帯域外の機構をサポートするスマートモバイルハンドセットに着地します。それはインターネットを介して適切なCPSを照会して、コールが撹拌対応装置によってそれに配置されたかどうかを判断します。それはEnterprise PBXによってプロビジョニングされたパスポートを見つけ、それを使用して発信者番号を確認します。
A call originates with an enterprise PBX that has both Internet access and a built-in gateway to the PSTN. It will immediately route the call to the PSTN, but before it does, it provisions a PASSporT with the CPS associated with the target telephone number. However, it turns out that the call will eventually route through the PSTN to an Internet gateway, which will translate this into a SIP call and deliver it to an administrative domain with a STIR verification service.
呼び出しは、インターネットアクセスとPSTNへの組み込みゲートウェイの両方を持つEnterprise PBXで発信されます。それはすぐにPSTNへの呼び出しをルーティングするでしょう、しかしそれがそうする前に、それはターゲット電話番号に関連するCPSのパスポートを規定しています。ただし、呼び出しは最終的にPSTNを介してインターネットゲートウェイにルーティングされます。これはこれをSIP呼び出しに変換し、それを撹拌検証サービスで管理ドメインに配信します。
In this case, there are two subcases for how the PASSporT might be retrieved. In subcase 1, the Internet gateway that receives the call from the PSTN could query the appropriate CPS to determine if the original caller created and provisioned a PASSporT for this call. If so, it can retrieve the PASSporT and, when it creates a SIP INVITE for this call, add a corresponding Identity header field per [RFC8224]. When the SIP INVITE reaches the destination administrative domain, it will be able to verify the PASSporT normally. Note that to avoid discrepancies with the Date header field value, only a full-form PASSporT should be used for this purpose. In subcase 2, the gateway does not retrieve the PASSporT itself, but instead the verification service at the destination administrative domain does so. Subcase 1 would perhaps be valuable for deployments where the destination administrative domain supports in-band STIR but not out-of-band STIR.
この場合、パスポートの取得方法については2つのサブケースがあります。SubCase 1では、PSTNから呼び出しを受け取るインターネットゲートウェイは適切なCPSを照会して、元の呼び出し側がこのコールのパスポートを作成してプロビジョニングしたかどうかを判断できます。もしそうなら、それはパスポートを取得することができ、そしてこの呼び出しのSIP INVITEを作成すると、[RFC8224]ごとに対応するIDヘッダーフィールドを追加します。SIP INVITEが宛先管理ドメインに達すると、パスポートを正常に検証することができます。日付ヘッダーフィールド値を使用した矛盾を回避するために、この目的のためにフルフォームパスポートのみを使用する必要があります。サブケース2では、ゲートウェイはパスポート自体を取得しませんが、その代わりに宛先管理ドメインの検証サービスはそうします。Subcase 1はおそらく、宛先管理ドメインが帯域内で帯状に攪拌をサポートしているが帯域外ではかき混ぜない展開にとっては貴重なものであろう。
A call originates in the SIP world in a STIR-aware administrative domain. The local authentication service for that administrative domain creates a PASSporT that is carried in band in the call per [RFC8224]. The call is routed out of the originating administrative domain and eventually reaches a gateway to the PSTN.
呼び出しは、攪拌対応管理ドメインでSIPの世界で発信されます。その管理ドメインのローカル認証サービスは、[RFC8224]ごとに電話でバンドで搭載されているパスポートを作成します。呼び出しは発信管理ドメインからルーティングされ、最終的にはPSTNへのゲートウェイに到達します。
In this case, the originating authentication service does not support the out-of-band mechanism, so instead the gateway to the PSTN extracts the PASSporT from the SIP request and provisions it to the CPS. (When the call reaches the gateway to the PSTN, the gateway might first check the CPS to see if a PASSporT object had already been provisioned for this call, and only provision a PASSporT if none is present).
この場合、発信元認証サービスは帯域外機構をサポートしていないため、PSTNへのゲートウェイはSIP要求からパスポートを抽出し、それをCPSに規定しています。（呼び出しがPSTNへのゲートウェイに達すると、最初にCPSがこのコールのためにすでにプロビジョニングされているかどうかを確認するためにCPSをチェックし、存在しない場合にのみパスポートをプロビジョニングします）。
Ultimately, the call may terminate on the PSTN or be routed back to a SIP environment. In the former case, perhaps the destination endpoint queries the CPS to retrieve the PASSporT provisioned by the first gateway. If the call ultimately returns to a SIP environment, it might be the gateway from the PSTN back to the Internet that retrieves the PASSporT from the CPS and attaches it to the new SIP INVITE it creates, or it might be the terminating administrative domain's verification service that checks the CPS when an INVITE arrives with no Identity header field. Either way, the PASSporT can survive the gap in SIP coverage caused by the PSTN leg of the call.
最終的には、呼び出しはPSTN上で終了するか、またはSIP環境にルーティングされます。前者の場合、おそらく宛先エンドポイントはCPSにクエリされ、最初のゲートウェイによってプロビジョニングされたパスポートを取得します。コールが最終的にSIP環境に戻ると、PSTNからのゲートウェイからCPSからパスポートを取得し、それを作成する新しいSIP INVITEに添付する、または終了した管理ドメインの検証サービスである可能性があります。INVITEがIDENTITITYヘッダーフィールドのない到着時にCPSをチェックします。どちらの方法でも、パスポートは、電話のPSTNの脚によって引き起こされるSIPカバレッジのギャップを生き残ることができます。
A call originates from a mobile user, and a STIR authentication service operated by their carrier creates a PASSporT for the call. As the carrier forwards the call via SIP, it attaches the PASSporT to the SIP call with an Identity header field. As a fallback in case the call will not go end-to-end over SIP, the carrier also stores the PASSporT in a CPS.
呼び出しはモバイルユーザから発信され、それらのキャリアによって操作される撹拌認証サービスはその通話のためにパスポートを作成する。キャリアがSIPを介して通話を転送すると、PassportをIDヘッダーフィールドでSIP呼び出しに添付します。呼び出しがSIPを終わらせない場合のフォールバックとして、キャリアはパスポートをCPSに保存します。
The call is then routed over SIP for a time, before it transitions to the PSTN and ultimately is handled by a legacy PBX at a high-volume call center. The call center supports the out-of-band service, and has a high-volume interface to a CPS to retrieve PASSporTs for incoming calls; agents at the call center use a general purpose computer to manage inbound calls and can receive STIR notifications through it. When the PASSporT arrives at the CPS, it is sent through a subscription/notification interface to a system that can correlate incoming calls with valid PASSporTs. The call center agent sees that a valid call from the originating number has arrived.
その後、呼び出しはPSTNに移行する前にSIPを介してルーティングされ、最終的には大量呼び出し中央のレガシPBXによって処理されます。コールセンターは帯域外サービスをサポートしており、着信コールのパスポートを取得するためのCPSへの大量のインターフェースを持ちます。コールセンターのエージェントは、汎用のコンピューターを使用して着信呼び出しを管理し、それを通して撹拌通知を受け取ることができます。パスポートがCPSに到着すると、受信通話を有効なパスポートと相関させることができるシステムへのサブスクリプション/通知インタフェースを介して送信されます。コールセンターエージェントは、発信番号からの有効な呼び出しが到着したことを示しています。
The use cases show a variety of entities accessing the CPS to store and retrieve PASSporTs. The question of how the CPS authorizes the storage and retrieval of PASSporTs is thus a key design decision in the architecture. The STIR architecture assumes that service providers and, in some cases, end-user devices will have credentials suitable for attesting authority over telephone numbers per [RFC8226]. These credentials provide the most obvious way that a CPS can authorize the storage and retrieval of PASSporTs. However, as use cases 3, 4, and 5 in Section 5 show, it may sometimes make sense for the entity storing or retrieving PASSporTs to be an intermediary rather than a device associated with either the originating or terminating side of a call; those intermediaries often would not have access to STIR credentials covering the telephone numbers in question. Requiring authorization based on a credential to store PASSporTs is therefore undesirable, though potentially acceptable if sufficient steps are taken to mitigate any privacy risk of leaking data.
USEケースは、パスポートを保存および取得するためにCPSにアクセスするさまざまなエンティティを表示します。そのため、パスポートの保管や検索がアーキテクチャでの重要な設計決定であることの問題は、その問題の問題の問題です。 STRICアーキテクチャは、サービスプロバイダーと、場合によっては、エンドユーザーデバイスが[RFC8226]あたりの電話番号に対する認証に適した資格情報を持つことを想定しています。これらの資格情報は、CPSがパスポートの保管と検索を許可できる最も明白な方法を提供します。しかしながら、セクション5の使用例3,4、および5が示されているので、呼び出しの発信側または終了側のいずれかに関連するデバイスではなく、パスポートを保存または検索するエンティティが検索または検索することが時には意味があるかもしれません。これらの仲介者はしばしば問題の電話番号を覆うかき混ぜる信任状にアクセスできないであろう。したがって、パスポートを保存する資格情報に基づく認証を要求することは望ましくありませんが、データ漏洩のプライバシーリスクを軽減するのに十分なステップが取られるのです。
It is an explicit design goal of this mechanism to minimize the potential privacy exposure of using a CPS. Ideally, the out-of-band mechanism should not result in a worse privacy situation than in-band STIR [RFC8224]: for in-band, we might say that a SIP entity is authorized to receive a PASSporT if it is an intermediate or final target of the routing of a SIP request. As the originator of a call cannot necessarily predict the routing path a call will follow, an out-of-band mechanism could conceivably even improve on the privacy story.
これは、CPSを使用する潜在的なプライバシーエクスポージャーを最小限に抑えるためのこのメカニズムの明白な設計目標です。理想的には、帯域外のメカニズムは、帯域内で帯域で悪化することよりも悪いプライバシー状況をもたらすべきではありません[RFC8224]：帯域内のために、それが中間であるならば、SIPエンティティはパスポートを受ける権限があると言うかもしれません。SIP要求のルーティングの最終目標呼び出し元の発信者が必ずしもルーティングパスを予測することはできないので、通話が続くと、帯域外のメカニズムがプライバシーストーリーを改善すると考えられる可能性があります。
Broadly, the architecture recommended here thus is one focused on permitting any entity to store encrypted PASSporTs at the CPS, indexed under the called number. PASSporTs will be encrypted with a public key associated with the called number, so these PASSporTs may safely be retrieved by any entity because only holders of the corresponding private key will be able to decrypt the PASSporT. This also prevents the CPS itself from learning the contents of PASSporTs, and thus metadata about calls in progress, which makes the CPS a less attractive target for pervasive monitoring (see [RFC7258]). As a first step, transport-level security can provide confidentiality from eavesdroppers for both the storing and retrieval of PASSporTs. To bolster the privacy story, to prevent denial-of-service flooding of the CPS, and to complicate traffic analysis, a few additional mechanisms are also recommended below.
概して、ここで推奨されているアーキテクチャは、任意のエンティティが呼び出された番号の下で索引付けされたCPSで暗号化されたパスポートを記憶することを可能にするものである。パスポートは、呼び出された番号に関連付けられている公開鍵で暗号化されます。そのため、対応する秘密鍵の保有者だけがパスポートを復号化できるため、これらのパスポートはあらゆるエンティティによって安全に取得される可能性があります。これはまた、CPS自体がパスポートの内容を学ぶこと、したがって通話中のメタデータを妨げることを防ぎ、CPSはPERVASIVEモニタリングのための魅力的な目標を低くする（[RFC7258]参照）。最初のステップとして、トランスポートレベルのセキュリティは、パスポートの保存と検索の両方のために盗聴者から機密性を提供できます。プライバシーストーリーを強化するために、CPSのサービス拒否フラッディングを防ぎ、トラフィック分析を複雑にするために、以下にいくつかの追加のメカニズムも推奨されます。
There are a few dimensions to authorizing the storage of PASSporTs. Encrypting PASSporTs prior to storage entails that a CPS has no way to tell if a PASSporT is valid; it simply conveys encrypted blocks that it cannot access itself and can make no authorization decision based on the PASSporT contents. There is certainly no prospect for the CPS to verify the PASSporTs itself.
パスポートの保管を承認するためのいくつかの寸法があります。ストレージの前にパスポートを暗号化することは、パスポートが有効かどうかを判断する方法がないことを伴います。それは単に暗号化されたブロックをそれ自身にアクセスできないことを伝え、パスポートの内容に基づいて権限決定をしないようにします。CPSがパスポート自体を検証するための見込みは確かにありません。
Note that this architecture requires clients that store PASSporTs to have access to an encryption key associated with the intended called party to be used to encrypt the PASSporT. Discovering this key requires the existence of a key lookup service (see Section 11), depending on how the CPS is architected; however, some kind of key store or repository could be implemented adjacent to it and perhaps even incorporated into its operation. Key discovery is made more complicated by the fact that there can potentially be multiple entities that have authority over a telephone number: a carrier, a reseller, an enterprise, and an end user might all have credentials permitting them to attest that they are allowed to originate calls from a number, say. PASSporTs for out-of-band use therefore might need to be encrypted with multiple keys in the hopes that one will be decipherable by the relying party.
このアーキテクチャでは、パスポートをパスポートの暗号化に使用するために使用される対象となるパーティーに関連する暗号化キーにアクセスできるようにするクライアントが必要です。このキーを検出するには、CPSが設計されている方法に応じて、キールックアップサービスの存在が必要です（セクション11を参照）。ただし、ある種のキーストアやリポジトリは、それに隣接して実装でき、おそらくその操作に組み込まれています。鍵の発見は、電話番号を超える権限を持つ複数のエンティティになる可能性があるという事実によって、キャリア、リセラー、企業、およびエンドユーザーがすべて資格情報を許可されていることを証明することを許可することができるという事実になります。言った番号からの呼び出しを発信します。したがって、帯域外の使用のためのパスポートは、希望当事者によって解読可能になることを期待して複数のキーで暗号化する必要があるかもしれません。
Again, the most obvious way to authorize storage is to require the originator to authenticate themselves to the CPS with their STIR credential. However, since the call is indexed at the CPS under the called number, this can weaken the privacy story of the architecture, as it reveals to the CPS both the identity of the caller and the callee. Moreover, it does not work for the gateway use cases described above; to support those use cases, we must effectively allow any entity to store PASSporTs at a CPS. This does not degrade the anti-impersonation security of STIR, because entities who do not possess the necessary credentials to sign the PASSporT will not be able to create PASSporTs that will be treated as valid by verifiers. In this architecture, it does not matter whether the CPS received a PASSporT from the authentication service that created it or from an intermediary gateway downstream in the routing path as in case 4 above. However, if literally anyone can store PASSporTs in the CPS, an attacker could easily flood the CPS with millions of bogus PASSporTs indexed under a calling number, and thereby prevent the called party from finding a valid PASSporT for an incoming call buried in a haystack of fake entries.
やはり、ストレージを承認するための最も明白な方法は、創作者が彼らのかき混ぜる信任状を持つCPSに自分自身を認証することを要求することです。ただし、呼び出しは呼び出された番号の下でCPSで索引付けされているため、これは、呼び出し元とCalleEの両方のIDの両方のCPSに明らかにされているため、アーキテクチャのプライバシーストーリーを弱めます。また、上記のゲートウェイの使用例では機能しません。これらのユースケースをサポートするには、すべてのエンティティがCPSでパスポートを保存できるようにする必要があります。これは、パスポートに署名するために必要な資格情報を持っていないエンティティが検証者によって有効であると扱われるパスポートを作成することができないため、これは攪拌の反力の防止セキュリティを低下させません。このアーキテクチャでは、CPSがそれを作成した認証サービスから、または上記のケース4のようにルーティングパスの下流の中間ゲートウェイからパスポートを受信したかどうかは関係ありません。ただし、文字通りCPSにパスポートを保存できる場合、攻撃者は電話番号の下で索引付けされた数百万のBogus PassportでCPSを簡単に洪水に洪水にし、それによって着信側が干しているコールに埋葬されたコールの有効なパスポートを見つけるのを防ぐことができます。偽のエントリ
The solution architecture must therefore include some sort of traffic control system to prevent flooding. Preferably, this should not require authenticating the source, as this will reveal to the CPS both the source and destination of traffic. A potential solution is discussed below in Section 7.5.
したがって、解決策アーキテクチャは、フラッディングを防ぐためにある種のトラフィック制御システムを含む必要があります。好ましくは、これはトラフィックの送信元と送信先の両方のCPSに明らかになるので、これはソースを認証することを要求してはならない。潜在的な解決策については、7.5節で以下に説明されています。
For retrieval of PASSporTs, this architecture assumes that clients will contact the CPS through some sort of polling or notification interface to receive all current PASSporTs for calls destined to a particular telephone number, or block of numbers.
パスポートの検索のために、このアーキテクチャは、特定の電話番号、または数のブロック宛のコールの現在のパスポートをすべて受け取るために、クライアントがある種のポーリングまたは通知インタフェースを通じてCPSに連絡することを前提としています。
As PASSporTs stored at the CPS are encrypted with a key belonging to the intended destination, the CPS can safely allow anyone to download PASSporTs for a called number without much fear of compromising private information about calls in progress -- provided that the CPS always returns at least one encrypted blob in response to a request, even if there was no call in progress. Otherwise, entities could poll the CPS constantly, or eavesdrop on traffic, to learn whether or not calls were in progress. The CPS MUST generate at least one unique and plausible encrypted response to all retrieval requests, and these dummy encrypted PASSporTs MUST NOT be repeated for later calls. An encryption scheme needs to be carefully chosen to make messages look indistinguishable from random when encrypted, so that information about the called party is not discoverable from legitimate encrypted PASSporTs.
CPSに保存されているパスポートが意図された宛先に属するキーで暗号化されているため、CPSは、通話中の通話に関する個人情報を犠牲にすることを恐れずに、電話番号のパスポートを安全にダウンロードできます。実行中の通話があったとしても、要求に応じて少なくとも1つの暗号化されたBLOB。それ以外の場合、エンティティはCPSを常にトラフィックでポーリングすることも、通話が進行中であるかどうかを学ぶことができます。CPSは、すべての検索要求に対して少なくとも1つの固有でもっともらしい暗号化された応答を生成しなければならず、これらのダミー暗号化パスポートは後で呼び出しのために繰り返されてはならない。暗号化されたときにメッセージをランダムと見なすようにするために、暗号化方式を慎重に選択する必要があります。そのため、呼び出し側の情報は正当な暗号化パスポートから発見できません。
Because the entity placing a call may discover multiple keys associated with the called party number, multiple valid PASSporTs may be stored in the CPS. A particular called party who retrieves PASSporTs from the CPS may have access to only one of those keys. Thus, the presence of one or more PASSporTs that the called party cannot decrypt -- which would be indistinguishable from the "dummy" PASSporTs created by the CPS when no calls are in progress - does not entail that there is no call in progress. A retriever likely will need to decrypt all PASSporTs retrieved from the CPS, and may find only one that is valid.
呼び出しを配置するエンティティは、呼び出されたパーティ番号に関連付けられている複数のキーを発見する可能性があるため、複数の有効なパスポートをCPSに保存できます。CPSからパスポートを取得する特定の当事者は、それらのキーのうちの1つだけにアクセスできるかもしれません。したがって、呼び出された当事者が復号化できない1つまたは複数のパスポートの存在は、通話が進行中のCPSによって作成された「ダミー」パスポートと区別がつかないであろう - 進行中の通話がないことを伴わない。RETRIEVERは、CPSから取得したすべてのパスポートを復号化する必要があり、有効なものだけを見つけることができます。
In order to prevent the CPS from learning the numbers that a callee controls, callees might also request PASSporTs for numbers that they do not own, that they have no hope of decrypting. Implementations could even allow a callee to request PASSporTs for a range or prefix of numbers: a trade-off where that callee is willing to sift through bulk quantities of undecryptable PASSporTs for the sake of hiding from the CPS which numbers it controls.
CPSがCALLEコントロールがコントロールする数字を学習するのを防ぐために、Calleesは、所有していない数字のパスポートを要求している可能性があります。実装では、CalleEが数字の範囲または接頭辞のためにパスポートを要求できるようになりました。
Note that in out-of-band call forwarding cases, special behavior is required to manage the relationship between PASSporTs using the diversion extension [PASSPORT-DIVERT]. The originating authentication service encrypts the initial PASSporT with the public encryption key of the intended destination, but once a call is forwarded, it may go to a destination that does not possess the corresponding private key and thus could not decrypt the original PASSporT. This requires the retargeting entity to generate encrypted PASSporTs that show a secure chain of diversion: a retargeting storer SHOULD use the "div-o" PASSporT type, with its "opt" extension, as specified in [PASSPORT-DIVERT], in order to nest the original PASSporT within the encrypted diversion PASSporT.
帯域外呼転送ケースでは、転換拡張[Passport-Diperert]を使用してパスポート間の関係を管理するために特別な動作が必要です。発信元認証サービスは、意図された宛先のパブリック暗号化キーで最初のパスポートを暗号化しますが、コールが転送されると、対応する秘密鍵を持たない目的地に進むことができ、したがって元のパスポートを復号化できませんでした。これには、セキュアの転送チェーンを示す暗号化パスポートを生成するためのRetargetingエンティティが必要です.Retargeting Storerは、[Passport-Diperert]で指定されている「OPT」のパスポートタイプを使用する必要があります。元のパスポートを暗号化された転換パスポート内に入れます。
In this section, we discuss a high-level architecture for providing the service described in the previous sections. This discussion is deliberately sketchy, focusing on broad concepts and skipping over details. The intent here is merely to provide an overall architecture, not an implementable specification. A more concrete example of how this might be specified is given in Section 9.
このセクションでは、前のセクションで説明されているサービスを提供するための高水準アーキテクチャについて説明します。この議論は、幅広い概念に焦点を当てて、詳細をスキップすることを目的としています。ここでの意図は単に実装可能な仕様ではなく、全体的なアーキテクチャを提供することです。これがどのように指定されているかのより具体的な例がセクション9に示されています。
We start from the premise of the STIR problem statement [RFC7340] that phone numbers can be associated with credentials that can be used to attest ownership of numbers. For purposes of exposition, we will assume that ownership is associated with the endpoint (e.g., a smartphone), but it might well be associated with a provider or gateway acting for the endpoint instead. It might be the case that multiple entities are able to act for a given number, provided that they have the appropriate authority. [RFC8226] describes a credential system suitable for this purpose; the question of how an entity is determined to have control of a given number is out of scope for this document.
電話番号の前提から、電話番号が数字の所有権を認めるために使用できる資格情報に関連付けることができることを模索します。博覧会の目的のために、所有権がエンドポイント（例えばスマートフォン）に関連付けられていると仮定しますが、代わりにエンドポイントに行動するプロバイダまたはゲートウェイに関連付けられている可能性があります。適切な権限があると、複数のエンティティが特定の番号に対して行動することができる場合であるかもしれません。[RFC8226]この目的に適した資格システムを説明しています。エンティティが特定の数字の制御を持つように決定されていることの問題は、この文書の範囲外です。
An overview of the basic calling and verification process is shown below. In this diagram, we assume that Alice has the number +1.111.555.1111 and Bob has the number +2.222.555.2222.
基本的な呼び出しと検証プロセスの概要を以下に示します。この図では、Aliceの数が1.111.555.1111にあり、BOBは2.222.555.2222を持ちます。
Alice Call Placement Service Bob
--------------------------------------------------------------------
Store Encrypted PASSporT for 2.222.555.2222 ->
2.222.555.2222 - >の暗号化パスポートを保存する
Call from 1.111.555.1111 ------------------------------------------>
<-------------- Request PASSporT(s)
for 2.222.555.2222
Obtain Encrypted PASSporT -------->
(2.222.555.2222, 1.111.555.1111)
[Ring phone with verified callerid = 1.111.555.1111]
[検証済みのCallerID = 1.111.555.1111]
When Alice wishes to make a call to Bob, she contacts the CPS and stores an encrypted PASSporT on the CPS indexed under Bob's number. The CPS then awaits retrievals for that number.
アリスがBobに電話をかけたい場合、彼女はCPSに連絡して、Bobの番号の下に索引付けされたCPSに暗号化されたパスポートを格納します。その後、CPSはその数の検索を待っています。
When Alice places the call, Bob's phone would usually ring and display Alice's number (+1.111.555.1111), which is informed by the existing PSTN mechanisms for relaying a calling party number (e.g., the Calling Party's Number (CIN) field of the Initial Address Message (IAM)). Instead, Bob's phone transparently contacts the CPS and requests any current PASSporTs for calls to his number. The CPS responds with any such PASSporTs (or dummy PASSporTs if no relevant ones are currently stored). If such a PASSporT exists, and the verification service in Bob's phone decrypts it using his private key, validates it, then Bob's phone can present the calling party number information as valid. Otherwise, the call is unverifiable. Note that this does not necessarily mean that the call is bogus; because we expect incremental deployment, many legitimate calls will be unverifiable.
アリスが電話をかけると、BOBの電話は通常、発信者番号を中継するための既存のPSTNメカニズム（例えば、最初のアドレスの呼び出し側の番号（CIN）フィールド）によって通知されるアリスの番号（1.111.555.1111）を指示します。メッセージ（IAM））。代わりに、Bobの電話はCPSに透過的に連絡を取り、現在のパスポートを自分の番号への通話に要求します。CPSは、そのようなパスポート（または関連するものが現在格納されていない場合はダミーパスポート）で応答します。そのようなパスポートが存在し、Bobの電話の検証サービスが彼の秘密鍵を使って復号化することを検証し、ボブの電話は発信側の番号情報を有効として提示することができます。それ以外の場合は、通話は不明です。これは必ずしも呼び出しが偽のものであるという意味ではありません。インクリメンタル展開が期待されているため、多くの正当な通話は確認不可能です。
The primary attack we seek to prevent is an attacker convincing the callee that a given call is from some other caller C. There are two scenarios to be concerned with:
私たちが防止しようとする主な攻撃は、与えられた呼び出しが他の発信者Cからのものであると着信者を説得することです。
1. The attacker wishes to impersonate a target when no call from that target is in progress.
1. 攻撃者は、そのターゲットからの通話が進行中のときにターゲットを偽装したいと考えています。
2. The attacker wishes to substitute himself for an existing call setup.
2. 攻撃者は既存の通話設定のために自分自身を代用したいと考えています。
If an attacker can inject fake PASSporTs into the CPS or in the communication from the CPS to the callee, he can mount either attack. As PASSporTs should be digitally signed by an appropriate authority for the number and verified by the callee (see Section 7.1), this should not arise in ordinary operations. Any attacker who is aware of calls in progress can attempt to mount a race to substitute themselves as described in Section 7.4. For privacy and robustness reasons, using TLS [RFC8446] on the originating side when storing the PASSporT at the CPS is RECOMMENDED.
攻撃者がCPSに偽のパスポートを注入すること、またはCPSからの通信でCPSへの通信を注入できる場合、彼はどちらの攻撃をマウントすることができます。パスポートは、CalleEによって適切な権限によってデジタル署名されるべきであるので（セクション7.1を参照）、これは通常の操作では発生するはずです。進行中の通話を知っている攻撃者は、セクション7.4で説明されているようにレースを自分自身に登録しようとする可能性があります。PRASSIONでパスポートを保存するときに、発信側のTLS [RFC8446]を使用するプライバシーと堅牢性の理由
The entire system depends on the security of the credential infrastructure. If the authentication credentials for a given number are compromised, then an attacker can impersonate calls from that number. However, that is no different from in-band STIR [RFC8224].
システム全体は、資格情報インフラストラクチャのセキュリティによって異なります。特定の数の認証資格情報が危険にさらされている場合、攻撃者はその番号から呼び出しを偽装することができます。しかしながら、それはバンド間攪拌率とは異なります[RFC8224]。
A secondary attack we must also prevent is denial-of-service against the CPS, which requires some form of rate control solution that will not degrade the privacy properties of the architecture.
二次攻撃はまた、Architectureのプライバシー特性を低下させない、CPSに対してサービス拒否を防ぐ必要があります。
All that the receipt of the PASSporT from the CPS proves to the called party is that Alice is trying to call Bob (or at least was as of very recently) -- it does not prove that any particular incoming call is from Alice. Consider the scenario in which we have a service that provides an automatic callback to a user-provided number. In that case, the attacker can try to arrange for a false caller-id value, as shown below:
CPSからのパスポートの受領者の受領者が証明されたパーティーに証明されているのは、AliceがBobを呼び出しようとしていることです（または少なくとも最近は非常に最近では）、特定の着信通話がAliceからのものであることを証明しません。ユーザー提供番号に自動コールバックを提供するサービスがあるシナリオを検討してください。その場合、攻撃者は以下のように誤った発信者ID値を配置しようとすることができます。
Attacker Callback Service CPS Bob
--------------------------------------------------------------------
Place call to Bob ---------->
(from 111.555.1111)
Store PASSporT for
CS:Bob ------------->
Call from Attacker (forged CS caller-id info) -------------------->
Call from CS ------------------------> X
<-- Retrieve PASSporT for CS:Bob
< - CSのパスポートを取得する：ボブ
PASSporT for CS:Bob ------------------------>
[Ring phone with callerid = 111.555.1111]
[CallerID = 111.555.1111
In order to mount this attack, the attacker contacts the Callback Service (CS) and provides it with Bob's number. This causes the CS to initiate a call to Bob. As before, the CS contacts the CPS to insert an appropriate PASSporT and then initiates a call to Bob. Because it is a valid CS injecting the PASSporT, none of the security checks mentioned above help. However, the attacker simultaneously initiates a call to Bob using forged caller-id information corresponding to the CS. If he wins the race with the CS, then Bob's phone will attempt to verify the attacker's call (and succeed since they are indistinguishable), and the CS's call will go to busy/voice mail/call waiting.
この攻撃をマウントするために、攻撃者はコールバックサービス（CS）に連絡してBobの番号を提供します。これにより、CSはBOBへの呼び出しを開始します。前のように、CSはCPSに連絡して適切なパスポートを挿入してからBOBへの呼び出しを開始します。それはパスポートを噴射する有効なCSであるため、上記のセキュリティチェックのどれもヘルプを援助しません。ただし、攻撃者は、CSに対応する偽造された発信者ID情報を使用してBOBへの呼び出しを同時に開始します。彼がCSとレースに勝利した場合、Bobの電話は攻撃者の電話の確認を試みる（そして、それらが区別がつかないので成功し、そしてCSの呼び出し）はビジー/ボイスメール/通話待ちに行くでしょう。
In order to prevent a passive attacker from using traffic analysis or similar means to learn precisely when a call is placed, it is essential that the connection between the caller and the CPS be encrypted as recommended above. Authentication services could store dummy PASSporTs at the CPS at random intervals in order to make it more difficult for an eavesdropper to use traffic analysis to determine that a call was about to be placed.
受動的な攻撃者がトラフィック分析または類似の手段を使用するのを防ぐために、通話が配置されたときに正確に学習することを正確に学習することは、発信者とCPSの間の接続が上記のように暗号化されることが不可欠です。認証サービスは、盗聴者が交通分析を使用して通話が配置されようとしていると判断するのをより困難にするために、CPSにダミーパスポートをランダムな間隔で保存することができます。
Note that in a SIP environment, the callee might notice that there were multiple INVITEs and thus detect this attack, but in some PSTN interworking scenarios, or highly intermediated networks, only one call setup attempt will reach the target. Also note that the success of this substitution attack depends on the attacker landing their call within the narrow window that the PASSporT is retained in the CPS, so shortening that window will reduce the opportunity for the attack. Finally, smart endpoints could implement some sort of state coordination to ensure that both sides believe the call is in progress, though methods of supporting that are outside the scope of this document.
SIP環境では、CalleEは複数の招待状があることに気付くことができ、したがってこの攻撃を検出したが、PSTNインターワーキングシナリオ、または非常に中間ネットワークでは、1回の通話セットアップの試みだけがターゲットに到達します。また、この置換攻撃の成功は、パスポートがCPSに保持されている狭いウィンドウ内のコールを着陸させる攻撃者によって異なりますので、そのウィンドウで攻撃の機会を短縮します。最後に、スマートエンドポイントは、この文書の範囲外のサポート方法であるが、両側が通話が進行中であると確実になることを確実にするためにある種の状態調整を実行することができる。
In order to prevent the flooding of a CPS with bogus PASSporTs, we propose the use of "blind signatures" (see [RFC5636]). A sender will initially authenticate to the CPS using its STIR credentials and acquire a signed token from the CPS that will be presented later when storing a PASSporT. The flow looks as follows:
Bogusパスポートを使用したCPSの洪水を防ぐために、「ブラインドシグニチャ」の使用を提案します（[RFC5636]参照）。送信者は最初にそのSTAを使用してCPSに認証され、パスポートを保存するときに後で提示されるCPSから署名されたトークンを取得します。フローは次のようになります。
Sender CPS
送信者CPS.
Authenticate to CPS --------------------->
Blinded(K_temp) ------------------------->
<------------- Sign(K_cps, Blinded(K_temp))
[Disconnect]
Sign(K_cps, K_temp)
Sign(K_temp, E(K_receiver, PASSporT)) --->
At an initial time when no call is yet in progress, a potential client connects to the CPS, authenticates, and sends a blinded version of a freshly generated public key. The CPS returns a signed version of that blinded key. The sender can then unblind the key and get a signature on K_temp from the CPS.
最初の時期にはまだ進行中の場合、潜在的なクライアントはCPSに接続し、認証を受け取り、新しく生成された公開鍵のブラインドされたバージョンを送信します。CPSはその盲目のキーの署名付きバージョンを返します。送信者はその後キーを切り離し、CPSからK_TEMPで署名を取得できます。
Then later, when a client wants to store a PASSporT, it connects to the CPS anonymously (preferably over a network connection that cannot be correlated with the token acquisition) and sends both the signed K_temp and its own signature over the encrypted PASSporT. The CPS verifies both signatures and, if they verify, stores the encrypted passport (discarding the signatures).
その後、クライアントがパスポートを保存したい場合は、CPSに匿名で接続します（好ましくはトークン取得と相関することはできません）、署名されたK_TEMPとそれ自身の署名の両方を暗号化パスポートを介して送信します。CPSは両方のシグネチャを検証し、検証した場合は暗号化パスポート（署名を破棄する）を保存します。
This design lets the CPS rate limit how many PASSporTs a given sender can store just by counting how many times K_temp appears; perhaps CPS policy might reject storage attempts and require acquisition of a new K_temp after storing more than a certain number of PASSporTs indexed under the same destination number in a short interval. This does not, of course, allow the CPS to tell when bogus data is being provisioned by an attacker, simply the rate at which data is being provisioned. Potentially, feedback mechanisms could be developed that would allow the called parties to tell the CPS when they are receiving unusual or bogus PASSporTs.
この設計により、CPSレートでは、特定の送信者が数回K_TEMPが表示されることをカウントすることによって、特定の送信者が格納できるパスポートの数を制限できます。おそらくCPSポリシーはストレージの試みを拒否し、同じ宛先番号の下で短い間隔で索引付けされたパスポートを複数のパスポートを記憶した後に新しいK_TEMPの取得を必要とする可能性があります。これは、もちろん、CPSがBogusデータが攻撃者によってプロビジョニングされているかどうかを判断することはできません。単にデータのプロビジョニングされているレートです。潜在的に、珍しいパスポートを受けているときに呼び出された当事者がCPSに伝えることを可能にするフィードバックメカニズムを開発することができます。
This architecture also assumes that the CPS will age out PASSporTs. A CPS SHOULD NOT keep any stored PASSporT for longer than the recommended freshness policy for the "iat" value as described in [RFC8224] (i.e., sixty seconds) unless some local policy for a CPS deployment requires a longer or shorter interval. Any reduction in this window makes substitution attacks (see Section 7.4) harder to mount, but making the window too small might conceivably age PASSporTs out while a heavily redirected call is still alerting.
このアーキテクチャはまた、CPSがパスポートを務めていると仮定しています。CPS展開のためのいくつかのローカルポリシーが長い間隔またはより短い間隔を必要としない限り、[RFC8224]（すなわち、60秒）の「IAT」値のための推奨されている鮮度ポリシーよりも長く保存されているパスポートを保存しないでください。このウィンドウの削減は、マウントが困難であるが、窓を小さすぎると、窓を小さすぎる可能性があると考えられる可能性がありますが、大幅にリダイレクトされた通話はまだ警戒しています。
An alternative potential approach to blind signatures would be the use of verifiable oblivious pseudorandom functions (VOPRFs, per [PRIVACY-PASS]), which may prove faster.
ブラインドシグネチャへの代替的な潜在的なアプローチは、検証可能な難解な疑似andom関数（voprfs、[プライバシーパスごと）の使用であろう。
[RFC8224] defines an authentication service and a verification service as functions that act in the context of SIP requests and responses. This specification thus provides a more generic description of authentication service and verification service behavior that might or might not involve any SIP transactions, but depends only on placing a request for communications from an originating identity to one or more destination identities.
[RFC8224] SIPリクエストや応答のコンテキストで機能する機能として、認証サービスと検証サービスを定義します。したがって、この仕様は、SIPトランザクションを含んでいる可能性がある、または何らかの情報の要求を1つまたは複数の宛先IDに配置することだけに依存する可能性がある、認証サービスおよび検証サービスの動作のより一般的な説明を提供します。
Out-of-band authentication services perform steps similar to those defined in [RFC8224] with some exceptions:
帯域外認証サービス[RFC8224]で定義されているものと同様の手順を実行します。
Step 1: The authentication service MUST determine whether it is authoritative for the identity of the originator of the request, that is, the identity it will populate in the "orig" claim of the PASSporT. It can do so only if it possesses the private key of one or more credentials that can be used to sign for that identity, be it a domain or a telephone number or some other identifier. For example, the authentication service could hold the private key associated with a STIR certificate [RFC8225].
ステップ1：認証サービスは、リクエストの発信者の身元、すなわちパスポートの「orig」クレームに入るアイデンティティに権限があるかどうかを判断する必要があります。それがその身元のために署名するために使用することができる1つ以上の認証情報の秘密鍵を所有している場合にのみ実行できます。また、ドメインまたは電話番号、またはその他の識別子です。たとえば、認証サービスは、撹拌証明書に関連する秘密鍵を保持することができます[RFC8225]。
Step 2: The authentication service MUST determine that the originator of communications can claim the originating identity. This is a policy decision made by the authentication service that depends on its relationship to the originator. For an out-of-band application built into the calling device, for example, this is the same check performed in Step 1: does the calling device hold a private key, one corresponding to a STIR certificate, that can sign for the originating identity?
ステップ2：認証サービスは、通信の発信者が発信側IDを主張できると判断する必要があります。これは、発信者との関係に依存する認証サービスによって行われた政策決定です。例えば、発呼装置に組み込まれている帯域外へのアプリケーションの場合、これはステップ1で実行されるのと同じチェックである：呼び出し側デバイスは秘密鍵を保持し、それは攻撃証明書に対応するものであり、それは発信側のアイデンティティに署名することができる。？
Step 3: The authentication service MUST acquire the public encryption key of the destination, which will be used to encrypt the PASSporT (see Section 11). It MUST also discover (see Section 10) the CPS associated with the destination. The authentication service may already have the encryption key and destination CPS cached, or may need to query a service to acquire the key. Note that per Section 7.5, the authentication service may also need to acquire a token for PASSporT storage from the CPS upon CPS discovery. It is anticipated that the discovery mechanism (see Section 10) used to find the appropriate CPS will also find the proper key server for the public key of the destination. In some cases, a destination may have multiple public encryption keys associated with it. In that case, the authentication service MUST collect all of those keys.
ステップ3：認証サービスは、パスポートの暗号化に使用される宛先のパブリック暗号化キーを取得する必要があります（セクション11を参照）。宛先に関連付けられているCPSを検出する必要があります（セクション10を参照）。認証サービスは、すでに暗号化キーおよび宛先CPSをキャッシュされているか、またはキーを取得するためにサービスを照会する必要があるかもしれない。セクション7.5あたり、認証サービスはまた、CPSディスカバリー時にCPSからパスポートストレージのトークンを取得する必要があるかもしれないことに注意してください。適切なCPSを見つけるために使用される発見メカニズム（セクション10を参照）も、宛先の公開鍵のための適切な鍵サーバーを見つけることが期待されています。場合によっては、宛先に複数のパブリック暗号化キーが関連付けられている可能性があります。その場合、認証サービスはそれらのすべてのキーを収集する必要があります。
Step 4: The authentication service MUST create the PASSporT object. This includes acquiring the system time to populate the "iat" claim, and populating the "orig" and "dest" claims as described in [RFC8225]. The authentication service MUST then encrypt the PASSporT. If in Step 3 the authentication service discovered multiple public keys for the destination, it MUST create one encrypted copy for each public key it discovered.
ステップ4：認証サービスはPassportオブジェクトを作成する必要があります。これには、[RFC8225]に記載されているように、「IAT」クレームを作成するためのシステム時間を取得し、「ORIG」と「DEST」クレームに移入することが含まれます。認証サービスはパスポートを暗号化する必要があります。ステップ3の場合、認証サービスは宛先の複数の公開鍵を発見した場合は、検出された公開鍵ごとに1つの暗号化されたコピーを作成する必要があります。
Finally, the authentication service stores the encrypted PASSporT(s) at the CPS discovered in Step 3. Only after that is completed should any call be initiated. Note that a call might be initiated over SIP, and the authentication service would place the same PASSporT in the Identity header field value of the SIP request -- though SIP would carry a cleartext version rather than an encrypted version sent to the CPS. In that case, out-of-band would serve as a fallback mechanism if the request was not conveyed over SIP end-to-end. Also, note that the authentication service MAY use a compact form of the PASSporT for a SIP request, whereas the version stored at the CPS MUST always be a full-form PASSporT.
最後に、認証サービスは、ステップ3で発見されたCPSに暗号化パスポートを格納します。呼び出しがSIPを介して開始される可能性があり、認証サービスはSIP要求のIDヘッダーフィールド値に同じパスポートを配置します - SIPはCPSに送信された暗号化バージョンではなくClearTextバージョンを運びます。その場合、要求がSIPエンドツーエンドを介して伝達されなかった場合、アウトオブバンドはフォールバックメカニズムとして機能します。また、認証サービスはSIPリクエストのためにコンパクトなパスポートを使用することができますが、CPSに保存されているバージョンは常にフルフォームのパスポートになる必要があります。
When a call arrives, an out-of-band verification service performs steps similar to those defined in [RFC8224] with some exceptions:
呼び出しが到着すると、帯域外の検証サービスは[RFC8224]で定義されているものと同様のステップをいくつか例外となります。
Step 1: The verification service contacts the CPS and requests all current PASSporTs for its destination number; or alternatively it may receive PASSporTs through a push interface from the CPS in some deployments. The verification service MUST then decrypt all PASSporTs using its private key. Some PASSporTs may not be decryptable for any number of reasons: they may be intended for a different verification service, or they may be "dummy" values inserted by the CPS for privacy purposes. The next few steps will narrow down the set of PASSporTs that the verification service will examine from that initial decryptable set.
ステップ1：検証サービスはCPSに連絡し、現在のすべてのパスポートをその宛先番号に要求します。あるいは、展開によっては、CPSからのプッシュインタフェースを介してパスポートを受け取ることがあります。検証サービスは、その秘密鍵を使ってすべてのパスポートを復号化する必要があります。一部のパスポートは任意の数の理由で復号化できない可能性があります。それらは異なる検証サービスを目的としているか、またはプライバシーの目的でCPによって挿入された「ダミー」の値である場合があります。次のいくつかのステップは、検証サービスがその初期復号化可能なセットから検討するパスポートのセットを絞り込みます。
Step 2: The verification service MUST determine if any "ppt" extensions in the PASSporTs are unsupported. It takes only the set of supported PASSporTs and applies the next step to them.
ステップ2：検証サービスは、パスポート内の「PPT」拡張機能がサポートされていないかどうかを判断する必要があります。サポートされているパスポートのセットしかかり、次のステップをそれらに適用します。
Step 3: The verification service MUST determine if there is an overlap between the calling party number presented in call signaling and the "orig" field of any decrypted PASSporTs. It takes the set of matching PASSporTs and applies the next step to them.
ステップ3：検証サービスは、呼シグナリングで提示された発信側番号と復号化されたパスポートの「orig」フィールドとの間に重複があるかどうかを判断する必要があります。一致するパスポートのセットを取り、次のステップをそれらに適用します。
Step 4: The verification service MUST determine if the credentials that signed each PASSporT are valid, and if the verification service trusts the CA that issued the credentials. It takes the set of trusted PASSporTs to the next step.
ステップ4：検証サービスは、各パスポートに署名された資格情報が有効であるかどうかを判断しなければならず、検証サービスが資格情報を発行したCAを信頼している場合。それは信頼できるパスポートのセットを次のステップに取ります。
Step 5: The verification service MUST check the freshness of the "iat" claim of each PASSporT. The exact interval of time that determines freshness is left to local policy. It takes the set of fresh PASSporTs to the next step.
ステップ5：検証サービスは各パスポートの「IAT」請求の鮮度をチェックする必要があります。鮮度を決定する正確な時間間隔は、ローカルポリシーに残されています。それは次のステップに新たなパスポートのセットを取ります。
Step 6: The verification service MUST check the validity of the signature over each PASSporT, as described in [RFC8225].
ステップ6：[RFC8225]で説明されているように、検証サービスは各パスポートの上の署名の妥当性を確認する必要があります。
Finally, the verification service will end up with one or more valid PASSporTs corresponding to the call it has received. In keeping with baseline STIR, this document does not dictate any particular treatment of calls that have valid PASSporTs associated with them; the handling of the call after the verification process depends on how the verification service is implemented and on local policy. However, it is anticipated that local policies could involve making different forwarding decisions in intermediary implementations, or changing how the user is alerted or how identity is rendered in user agent implementations.
最後に、検証サービスは、受信した呼に対応する1つ以上の有効なパスポートを終わらせることになります。ベースラインをかき混ぜることで、この文書はそれらに関連付けられている有効なパスポートを持つ呼の特定の扱いを決定するものではありません。検証プロセスの後の呼び出しの処理は、検証サービスの実装方法およびローカルポリシーにかかっています。ただし、ローカルポリシーは、中間の実装で異なる転送決定を行うこと、またはユーザーがどのように警告されているか、またはユーザーエージェント実装でどのようにどのようにレンダリングされるかを変更することが期待されています。
The STIR out-of-band mechanism also supports the presence of gateway placement services, which do not create PASSporTs themselves, but instead take PASSporTs out of signaling protocols and store them at a CPS before gatewaying to a protocol that cannot carry PASSporTs itself. For example, a SIP gateway that sends calls to the PSTN could receive a call with an Identity header field, extract a PASSporT from the Identity header field, and store that PASSporT at a CPS.
帯域外のメカニズムはまた、パスポート自体を作成しないが、パスポート自体を運ぶことができないプロトコルに入金する前に、シグナリングプロトコルからパスポートを取り出し、それらをCPSに保存するゲートウェイプレースメインサービスの存在をサポートします。たとえば、PSTNへの呼び出しを送信するSIPゲートウェイは、Identity Headerフィールドを使用して呼び出しを受け取り、IDヘッダーフィールドからパスポートを抽出し、そのパスポートをCPSに保存します。
To place a PASSporT at a CPS, a gateway MUST perform Step 3 of Section 8.1 above: that is, it must discover the CPS and public key associated with the destination of the call, and may need to acquire a PASSporT storage token (see Section 6.1). Per Step 3 of Section 8.1, this may entail discovering several keys. The gateway then collects the in-band PASSporT(s) from the in-band signaling, encrypts the PASSporT(s), and stores them at the CPS.
パスポートをCPSに配置するには、ゲートウェイが上記のセクション8.1のステップ3を実行する必要があります。つまり、コールの宛先に関連付けられているCPSと公開鍵を発見する必要があり、パスポートストレージトークンを取得する必要があるかもしれません（セクションを参照）。6.1）。セクション8.1のステップ3ごとに、これはいくつかのキーを発見する必要があります。その後、ゲートウェイはインバンドシグナリングからインバンドパスポートを収集し、パスポートを暗号化し、それらをCPSに格納します。
A similar service could be performed by a gateway that retrieves PASSporTs from a CPS and inserts them into signaling protocols that support carrying PASSporTs in-band. This behavior may be defined by future specifications.
同様のサービスは、CPSからパスポートを取得し、それらを帯域内のパスポートを搭載したシグナリングプロトコルに挿入するゲートウェイによって実行できます。この動作は将来の仕様によって定義されるかもしれません。
As a rough example, we show a CPS implementation here that uses a Representational State Transfer (REST) API [REST] to store and retrieve objects at the CPS. The calling party stores the PASSporT at the CPS prior to initiating the call; the PASSporT is stored at a location at the CPS that corresponds to the called number. Note that it is possible for multiple parties to be calling a number at the same time, and that for called numbers such as large call centers, many PASSporTs could legitimately be stored simultaneously, and it might prove difficult to correlate these with incoming calls.
概略的な例として、ここでは、CPSの実装がCPSでオブジェクトを保存および取得するために、表現状態転送（REST）API [REST]を使用するCPS実装を示しています。呼び出し側は、通話を開始する前にパスポートをCPSに格納する。パスポートは、着信番号に対応するCPSの場所に格納されています。複数の当事者が同時に番号を呼び出すことが可能であり、大規模なコールセンターなどの呼び出し番号のために、多くのパスポートが同時に記憶される可能性があり、それらを着信通話と相関させることが困難である可能性があります。
Assume that an authentication service has created the following PASSporT for a call to the telephone number 2.222.555.2222 (note that these are dummy values):
認証サービスが電話番号2.222.555.2222222への呼び出しに次のパスポートを作成したとします（これらはダミー値です）。
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9
jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI
jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6
IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd
3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ
Through some discovery mechanism (see Section 10), the authentication service discovers the network location of a web service that acts as the CPS for 2.222.555.2222. Through the same mechanism, we will say that it has also discovered one public encryption key for that destination. It uses that encryption key to encrypt the PASSporT, resulting in the encrypted PASSporT:
いくつかの発見メカニズムを通して（セクション10を参照）、認証サービスは、2.222.555.2222のCPSとして機能するWebサービスのネットワークの場所を検出します。同じメカニズムを通して、それがその目的のために1つの公開暗号化キーを発見したと言うでしょう。その暗号化キーを使用してパスポートを暗号化し、その結果、暗号化パスポートが発生します。
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
Having concluded the numbered steps in Section 8.1, including acquiring any token (per Section 6.1) needed to store the PASSporT at the CPS, the authentication service then stores the encrypted PASSporT:
CPSにパスポートを保存するために必要なトークン（6.1節あたり）の取得を含むセクション8.1の番号付きステップを締めくくり、認証サービスは暗号化されたパスポートを格納します。
POST /cps/2.222.555.2222/ppts HTTP/1.1
Host: cps.example.com
Content-Type: application/passport
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
The web service assigns a new location for this encrypted PASSporT in the collection, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/ppt1. Now the authentication service can place the call, which may be signaled by various protocols. Once the call arrives at the terminating side, a verification service contacts its CPS to ask for the set of incoming calls for its telephone number (2.222.222.2222).
Webサービスは、この暗号化パスポートの新しい場所をコレクション内に割り当て、/ CPS / 2.2222222222 / ppts/ppt1の場所で201 OKを返します。これで認証サービスはコールを配置することができます。これはさまざまなプロトコルによって通知される可能性があります。通話が終了側に到着すると、検証サービスはそのCPSに連絡して、その電話番号の着信呼び出しのセットを要求する（2.22222222222）。
GET /cps/2.222.555.2222/ppts
Host: cps.example.com
This returns to the verification service a list of the PASSporTs currently in the collection, which currently consists of only /cps/2.222.222.2222/ppts/ppt1. The verification service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields:
これは、現在コレクション内のパスポートのリストを検証サービスに戻ります。これは、現在/cps / 2.222222222/ppts/ppt1のみで構成されています。検証サービスは/ cps / 2.222.555.222/ppts/ppt1/に新しいGETを送信します。
HTTP/1.1 200 OK
Content-Type: application/passport
Link: <https://cps.example.com/cps/2.222.555.2222/ppts>
rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w
MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm
nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV
wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1
IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j
That concludes Step 1 of Section 8.2; the verification service then goes on to the next step, processing that PASSporT through its various checks. A complete protocol description for CPS interactions is left to future work.
それはセクション8.2のステップ1を終了する。検証サービスは次のステップに進み、そのパスポートをさまざまな小切手を通じて処理します。CPSインタラクションの完全なプロトコル記述は将来の作業に残されています。
In order for the two ends of the out-of-band dataflow to coordinate, they must agree on a way to discover a CPS and retrieve PASSporT objects from it based solely on the rendezvous information available: the calling party number and the called number. Because the storage of PASSporTs in this architecture is indexed by the called party number, it makes sense to discover a CPS based on the called party number as well. There are a number of potential service discovery mechanisms that could be used for this purpose. The means of service discovery may vary by use case.
アウトオブバンドデータフローの両端が調整するためには、CPSを発見する方法に同意する必要があります。発信側の番号と呼び出された番号。このアーキテクチャのパスポートの保管は、被呼者番号によって索引付けされているため、着信側の番号に基づいてCPSを発見することは理にかなっています。この目的のために使用することができる多くの潜在的なサービス発見メカニズムがいくつかあります。サービス発見手段はユースケースによって異なる場合があります。
Although the discussion above is written largely in terms of a single CPS, having a significant fraction of all telephone calls result in storing and retrieving PASSporTs at a single monolithic CPS has obvious scaling problems, and would as well allow the CPS to gather metadata about a very wide set of callers and callees. These issues can be alleviated by operational models with a federated CPS; any service discovery mechanism for out-of-band STIR should enable federation of the CPS function. Likely models include ones where a carrier operates one or more CPS instances on behalf of its customers, an enterprise runs a CPS instance on behalf of its PBX users, or a third-party service provider offers a CPS as a cloud service.
上記の議論は単一のCPの点で主に書かれていますが、すべての電話の大部分を持つことは、単一のモノリシックCPSでパスポートを保存し検索することになります。これは明らかなスケーリングの問題を抱えており、CPSが発信者と着信者の非常に広いセットです。これらの問題は、連合CPSを持つ運用モデルによって軽減できます。帯域外衝突のためのサービス発見メカニズムは、CPS機能の連携を可能にする必要があります。可能性の高いモデルには、キャリアが顧客に代わって1つ以上のCPSインスタンスを操作するものが含まれており、エンタープライズはPBXユーザーに代わってCPSインスタンスを実行したり、サードパーティのサービスプロバイダーがクラウド・サービスとしてCPSを提供しています。
Some service discovery possibilities under consideration include the following:
検討中の一部のサービス発見の可能性は、次のものを含みます。
For some deployments in closed (e.g., intra-network) environments, the CPS location can simply be provisioned in implementations, obviating the need for a discovery protocol.
一部の展開（たとえば、ネットワーク内）環境では、CPSの場所は単純に実装でプロビジョニングされ、ディスカバリプロトコルの必要性を回避できます。
If a credential lookup service is already available (see Section 11), the CPS location can also be recorded in the callee's credentials; an extension to [RFC8226] could, for example, provide a link to the location of the CPS where PASSporTs should be stored for a destination.
信任状ルックアップサービスがすでに利用可能な場合（セクション11を参照）、CPSの場所はCalleeの資格情報に記録することもできます。[RFC8226]の拡張は、たとえば、パスポートを宛先に格納する必要があるCPSの場所へのリンクを提供できます。
There exist a number of common directory systems that might be used to translate telephone numbers into the URIs of a CPS. ENUM [RFC6116] is commonly implemented, though no "golden root" central ENUM administration exists that could be easily reused today to help the endpoints discover a common CPS. Other protocols associated with queries for telephone numbers, such as the Telephone-Related Information (TeRI) protocol [MODERN-TERI], could also serve for this application.
電話番号をCPSのURIに変換するために使用される可能性がある多数の一般的なディレクトリシステムがあります。ENUM [RFC6116]は一般的に実装されていますが、エンドポイントが一般的なCPSを発見するのを助けるために今日簡単に再利用できます。電話関連情報（TERI）プロトコルのような電話番号のクエリに関連する他のプロトコルもこのアプリケーションにも役立ちます。
Another possibility is to use a single distributed service for this function. Verification Involving PSTN Reachability (VIPR) [VIPR-OVERVIEW] proposed a REsource LOcation And Discovery (RELOAD) [RFC6940] usage for telephone numbers to help direct calls to enterprises on the Internet. It would be possible to describe a similar RELOAD usage to identify the CPS where calls for a particular telephone number should be stored. One advantage that the STIR architecture has over VIPR is that it assumes a credential system that proves authority over telephone numbers; those credentials could be used to determine whether or not a CPS could legitimately claim to be the proper store for a given telephone number.
もう1つの可能性は、この機能に単一の分散サービスを使用することです。PSTN到達可能性（VIPR）[VIPR-overView]の検証は、インターネット上の企業への電話を直接するのを助けるために、電話番号のためのリソースの場所と発見（RELOAD）[RFC6940]の使用法を提案しました。特定の電話番号の呼び出しを保存する必要があるCPSを識別するための同様のリロード使用法を説明することが可能です。Sticle ArchitectureがViPRを超えると、電話番号を超える権限を証明する信任状システムを仮定するという利点1。これらの資格情報は、CPSが特定の電話番号の適切な店舗であると判断できるかどうかを判断するために使用できます。
This document does not prescribe any single way to do service discovery for a CPS; it is envisioned that initial deployments will provision the location of the CPS at the authentication service and verification service.
この文書は、CPSのサービス検出を行うための単一の方法を規定していません。初期の展開では、認証サービスと検証サービスでCPSの場所をプロビジョニングすることが想定されています。
In order to encrypt a PASSporT (see Section 6.1), the caller needs access to the callee's public encryption key. Note that because STIR uses the Elliptic Curve Digital Signature Algorithm (ECDSA) for signing PASSporTs, the public key used to verify PASSporTs is not suitable for this function, and thus the encryption key must be discovered separately. This requires some sort of directory/lookup system.
パスポートを暗号化するため（セクション6.1を参照）、発信者はCalleeのパブリック暗号化キーにアクセスする必要があります。Passportsの署名に使用される楕円曲線デジタル署名アルゴリズム（ECDSA）を使用するため、パスポートを検証するために使用される公開鍵はこの機能には適していないため、暗号化キーは別々に発見されなければなりません。これにはある種のディレクトリ/ルックアップシステムが必要です。
Some initial STIR deployments have fielded certificate repositories so that verification services can acquire the signing credentials for PASSporTs, which are linked through a URI in the "x5u" element of the PASSporT. These certificate repositories could clearly be repurposed for allowing authentication services to download the public encryption key for the called party -- provided they can be discovered by calling parties. This document does not specify any particular discovery scheme, but instead offers some general guidance about potential approaches.
検証サービスがパスポートの「X5U」要素のURIを介してリンクされているパスポートの署名資格情報を取得できるように、いくつかの最初の攪拌展開がフィールドの証明書リポジトリを提供しています。これらの証明書リポジトリは、認証サービスが呼び出されたパーティーのためのパブリック暗号化キーをダウンロードすることを可能にするために明確に再利用することができます。この文書では特定の発見スキームは指定されていませんが、代わりに潜在的なアプローチに関する一般的なガイダンスを提供します。
It is a desirable property that the public encryption key for a given party be linked to their STIR credential. An Elliptic Curve Diffie-Hellman (ECDH) [RFC7748] public-private key pair might be generated for a subcert [TLS-SUBCERTS] of the STIR credential. That subcert could be looked up along with the STIR credential of the called party. Further details of this subcert, and the exact lookup mechanism involved, are deferred for future protocol work.
与えられた当事者に対するパブリック暗号化キーが彼らのかき混ぜる信任状にリンクさせることが望ましい特性です。楕円曲線Diffie-Hellman（ECDH）[RFC7748] STRACH信用証明書のサブセルテン・サブセルターのためにパブリック秘密鍵のペアが生成されることがあります。そのサブセントは着信側の攪拌資格と一緒に調べることができます。このサブ事故のさらなる詳細、および関与する正確なルックアップメカニズムは、将来のプロトコル作業のために繰り返されます。
Obviously, if there is a single central database that the caller and callee each access in real time to download the other's keys, then this represents a real privacy risk, as the central key database learns about each call. A number of mechanisms are potentially available to mitigate this:
明らかに、他のキーをダウンロードするためにリアルタイムで各アクセスがリアルタイムでアクセスした単一の中央データベースがある場合、これは中央キーデータベースが各呼び出しについて学習するため、実際のプライバシーリスクを表します。これを軽減するために多数のメカニズムが潜在的に利用可能です。
Have endpoints pre-fetch keys for potential counterparties (e.g., their address book or the entire database).
エンドポイントは、潜在的な取引先（例えば、アドレス帳またはデータベース全体の）のためのキーを事前にフェッチします。
Have caching servers in the user's network that proxy their fetches and thus conceal the relationship between the user and the keys they are fetching.
ユーザーのネットワーク内のキャッシングサーバーが、自分のフェッチをプロキシして、ユーザーとそれらがフェッチしているキーの関係を隠していることがあります。
Clearly, there is a privacy/timeliness trade-off in that getting up-to-date knowledge about credential validity requires contacting the credential directory in real-time (e.g., via the Online Certificate Status Protocol (OCSP) [RFC6960]). This is somewhat mitigated for the caller's credentials in that he can get short-term credentials right before placing a call which only reveals his calling rate, but not who he is calling. Alternately, the CPS can verify the caller's credentials via OCSP, though of course this requires the callee to trust the CPS's verification. This approach does not work as well for the callee's credentials, but the risk there is more modest since an attacker would need to both have the callee's credentials and regularly poll the database for every potential caller.
明らかに、信任状の妥当性に関する最新の知識を得ることは、資格情報ディレクトリについてリアルタイムで（オンライン証明書ステータスプロトコル（OCSP）[RFC6960]を介して）信用証明書ディレクトリに連絡することを必要とするという点で、プライバシー/タイムレベルのトレードオフがあります。彼が彼の呼び出し率を明らかにしかないが彼が呼び出しているのではなく、電話をかける直前に短期資格情報を得ることができるということで、これは彼が短期的な資格情報を得ることができるということである。あるいは、CPSはOCSPを介して呼び出し側の認証情報を検証することができますが、これはCAlleEがCPSの検証を信頼する必要があります。このアプローチもCalleeの資格情報だけでなく機能しませんが、攻撃者がCalleeの資格情報を持ち、すべての潜在的な発信者に対して定期的にデータベースをポーリングする必要があるため、より控えめにもっと控えめなリスクがあります。
We consider the exact best point in the trade-off space to be an open issue.
私たちは、トレードオフのスペースの正確な最良の点を開かれている問題と考えています。
This document has no IANA actions.
この文書にはIANAの行動がありません。
Delivering PASSporTs out-of-band offers a different set of privacy properties than traditional in-band STIR. In-band operations convey PASSporTs as headers in SIP messages in cleartext, which any forwarding intermediaries can potentially inspect. By contrast, out-of-band STIR stores these PASSporTs at a service after encrypting them as described in Section 6, effectively creating a path between the authentication and verification service in which the CPS is the sole intermediary, but the CPS cannot read the PASSporTs. Potentially, out-of-band PASSporT delivery could thus improve on the privacy story of STIR.
Passportsの配信バンドは、伝統的な帯域内での交換よりも異なるプライバシー特性のセットを提供しています。インバンド操作は、パスポートをSIPメッセージのヘッダーとしてClearTextのヘッダーとして伝えます。対照的に、帯域外攻撃は、セクション6で説明されているようにそれらを暗号化した後にサービスでこれらのパスポートをサービスに保存し、CPSが唯一の仲介者である認証および検証サービス間の経路を効果的に作成しますが、CPSはパスポートを読むことができません。。潜在的に、帯域外のパスポートの配達は、かき混ぜるプライバシーストーリーを向上させることができます。
The principle actors in the operation of out-of-band are the AS, VS, and CPS. The AS and VS functions differ from baseline behavior [RFC8224], in that they interact with a CPS over a non-SIP interface, of which the REST interface in Section 9 serves as an example. Some out-of-band deployments may also require a discovery service for the CPS itself (Section 10) and/or encryption keys (Section 11). Even with encrypted PASSporTs, the network interactions by which the AS and VS interact with the CPS, and to a lesser extent any discovery services, thus create potential opportunities for data leakage about calling and called parties.
帯域外帯の操作における原理アクターは、AS、VS、およびCPSです。ASおよびVS関数は、ベースライン動作[RFC8224]とは、SIP以外のインターフェイスを介してCPと対話します。そのうちセクション9のRESTインタフェースは例として機能します。いくつかの帯域外展開は、CPS自体の発見サービス（第10章）および/または暗号化キー（セクション11）を必要とする可能性がある。暗号化されたパスポートでさえ、ASとVSがCPと対話するネットワークの対話、およびその発見サービスがより少ない範囲であるため、締約国の呼び出しと呼び出し側のデータ漏洩の潜在的な機会が生まれます。
The process of storing and retrieving PASSporTs at a CPS can itself reveal information about calls being placed. The mechanism takes care not to require that the AS authenticate itself to the CPS, relying instead on a blind signature mechanism for flood control prevention. Section 7.4 discusses the practice of storing "dummy" PASSporTs at random intervals to thwart traffic analysis, and as Section 8.2 notes, a CPS is required to return a dummy PASSporT even if there is no PASSporT indexed for that calling number, which similarly enables the retrieval side to randomly request PASSporTs when there are no calls in progress. Note that the caller's IP address itself leaks information about the caller. Proxying the storage of the CPS through some third party could help prevent this attack. It might also be possible to use a more sophisticated system such as Riposte [RIPOSTE]. These measures can help to mitigate information disclosure in the system. In implementations that require service discovery (see Section 10), perhaps through key discovery (Section 11), similar measures could be used to make sure that service discovery does not itself disclose information about calls.
CPSでパスポートを保存および取得するプロセス自体が、配置されている通話に関する情報を明らかにすることができます。このメカニズムは、洪水制御防止のためのブラインド署名メカニズムに代わるように頼って、CPSをCPSに認証することを要求しないように注意します。第7.4節では、トラフィック分析の妨害時のランダムな間隔で「ダミー」パスポートを格納することの実践を議論し、セクション8.2の注意事項として、その呼び出し番号のためにパスポートが索引付けされていなくてもダミーのパスポートを返すためにCPSが必要です。進行中の通話がないときにパスポートをランダムに要求するための検索側。発信者のIPアドレス自体は発信者に関する情報をリークします。いくつかの第三者を通してCPSの保管をプロキシすると、この攻撃を防ぐのに役立ちます。 Raposte [Raposte]など、より洗練されたシステムを使用することも可能です。これらの対策は、システム内の情報開示を軽減するのに役立ちます。サービスの発見を必要とする実装（セクション10を参照）では、おそらく重要な検出を通して（セクション11）、サービスの発見がそれ自体が電話に関する情報を開示していないことを確認するために同様の方法を使用することができます。
Ultimately, this document only provides a framework for future implementation of out-of-band systems, and the privacy properties of a given implementation will depend on architectural assumptions made in those environments. More closed systems for intranet operations may adopt a weaker security posture but otherwise mitigate the risks of information disclosure, whereas more open environments will require careful implementation of the practices described here.
最終的には、この文書は帯域外システムの将来の実装のためのフレームワークのみを提供し、特定の実装のプライバシー特性はそれらの環境で行われたアーキテクチャの仮定に依存します。イントラネット操作のためのより密閉されたシステムは、より弱いセキュリティ姿勢を採用するかもしれませんが、情報開示のリスクを軽減するのに対して、より多くのオープンな環境はここで説明されている慣行の慎重な実施を必要とするでしょう。
For general privacy risks associated with the operations of STIR, also see the privacy considerations covered in Section 11 of [RFC8224].
撹拌の操作に関連する一般的なプライバシーリスクについては、[RFC8224]の第11章で説明されているプライバシーに関する考慮事項も参照してください。
This entire document is about security, but the detailed security properties will vary depending on how the framework is applied and deployed. General guidance for dealing with the most obvious security challenges posed by this framework is given in Sections 7.3 and 7.4, along proposed solutions for problems like denial-of-service attacks or traffic analysis against the CPS.
このドキュメント全体はセキュリティについてですが、詳細なセキュリティプロパティはフレームワークの適用およびデプロイ方法によって異なります。この枠組みによって提起された最も明白なセキュリティ上の課題を扱うための一般的なガイダンスは、サービス拒否攻撃やCPに対する交通分析などの問題のための提案された解決策に沿って、7.3および7.4のセクション7.3および7.4に記載されている。
Although there are considerable security challenges associated with widespread deployment of a public CPS, those must be weighed against the potential usefulness of a service that delivers a STIR assurance without requiring the passage of end-to-end SIP. Ultimately, the security properties of this mechanism are at least comparable to in-band STIR: the substitution attack documented in Section 7.4 could be implemented by any in-band SIP intermediary or eavesdropper who happened to see the PASSporT in transit, say, and launched its own call with a copy of that PASSporT to race against the original to the destination.
公共のCPSの広範な展開に関連するかなりのセキュリティ上の課題がありますが、エンドツーエンドのSIPの通過を必要とせずに撹拌保証を実現するサービスの潜在的な有用性に対して秤量する必要があります。最終的には、このメカニズムのセキュリティ特性は、帯域内攻撃に少なくとも匹敵する。セクション7.4に記載されている置換攻撃は、トランジット中のパスポートを見て起こった帯域内のSIP仲介者または盗聴者によって実施することができた。そのパスポートのコピーを宛先に競合するためにそのパスポートのコピー。
[MODERN-TERI] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", Work in Progress, Internet-Draft, draft-ietf-modern-teri-00, 2 July 2018, <https://tools.ietf.org/html/draft-ietf-modern-teri-00>.
[現代のテリ] Peterson、J。、「電話関連情報のためのアーキテクチャと情報モデル（テリ）」、進行中の作業、インターネットドラフト、ドラフト - IETF-MODER-TERI-TERI-TERI-TER-00、<HTTPS：//tools.ietf.org/html/draft-ietf-modern-teri-00>。
[PASSPORT-DIVERT] Peterson, J., "PASSporT Extension for Diverted Calls", Work in Progress, Internet-Draft, draft-ietf-stir-passport-divert-09, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-stir-passport-divert-09>.
[Passport-Dipert] Peterson、J.、「Diperted Callsのパスポート拡張」、進行中の作業、インターネットドラフト、ドラフト-IETF-STIL-PASSIOSP-DIVERT-09,2020 <https：//tools.ietf.org / html / draft-ietf-stic-passport-dipert-09>。
[PRIVACY-PASS] Davidson, A. and N. Sullivan, "The Privacy Pass Protocol", Work in Progress, Internet-Draft, draft-privacy-pass-00, 3 November 2019, <https://tools.ietf.org/html/draft-privacy-pass-00>.
[Privacy-Pass] Davidson、A.およびN.Sullivan、 "Privacy Pass Protocol"、進行中の作業、インターネットドラフト、ドラフト - プライバシーパス-00,31月3日、<https：//tools.ietf。org / html / draft-privacy-pass-00>。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Chapter 5: Representational State Transfer", Ph.D. Dissertation, University of California, Irvine, 2010.
[REST]フィールド化、R.、「ネットワークベースのソフトウェアアーキテクチャの設計、第5章：代表状態転送」、PH.D。カリフォルニア大学、アーバイン、2010年。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent, "Traceable Anonymous Certificate", RFC 5636, DOI 10.17487/RFC5636, August 2009, <https://www.rfc-editor.org/info/rfc5636>.
[RFC5636]公園、S、Park、H.、Wan、Y.、Lee、J.、およびS. Kent、「Traceable Anonymous Certificate」、RFC 5636、DOI 10.17487 / RFC 5636、2009年8月、<https：//www.rfc-editor.org/info/rfc5636>。
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <https://www.rfc-editor.org/info/rfc6116>.
[RFC6116] Bradner、S.、Conroy、L.、K. Fujiwara、「統一資源識別子（URI）動的代表団発見システム（DDDS）アプリケーション（enum）」、RFC 6116、DOI 10.17487 / RFC61162011年3月、<https：//www.rfc-editor.org/info/rfc6116>。
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, <https://www.rfc-editor.org/info/rfc6940>.
[RFC6940]ジェニングニング、C、ローカンプ、B.、ED、Rescorla、E.、Baset、S.、およびH.Schulzrinne、「リソースロケーションとディスカバリー」、RFC 6940、DOI 10.17487 / RFC6940、2014年1月、<https：//www.rfc-editor.org/info/rfc6940>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S、Myers、M.、Ankney、R.、Malpani、A.、Galparin、S、およびC. ADAMS、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC6960、DOI 10.17487 / RFC6960、2013年6月、<https：//www.rfc-editor.org/info/rfc6960>。
[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>.
[RFC7258] Farrell、S.およびH.Tschofenig、「Pervasive Monitoringは攻撃」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<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>.
[RFC7340] Peterson、J.、Schulzrinne、H.、H。Tschofenig、「安全な電話アイデンティティーの声明および要件」、RFC 7340、DOI 10.17487 / RFC7340、2014年9月、<https：//www.rfc-編集者。org / info / rfc7340>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748] Langley、A。、Hamburg、M.、S. Turner、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<https：//www.rfc-editor.org/info/ RFC7748>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8224] Peterson、J.、Jennings、C、Rescorla、E.、およびC.Wendt、「セッション開始プロトコル（SIP）」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<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>.
[RFC8225] Wendt、C.およびJ.Peterson、 "Passport：Personal Assertion Token"、RFC 8225、DOI 10.17487 / RFC8225、2018年2月、<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>.
[RFC8226] Peterson、J.およびS. Turner、「Secure Phereth Identity Credentials：証明書」、RFC 8226、DOI 10.17487 / RFC8226、2018年2月、<https：//www.rfc-editor.org/info/rfc8226>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RIPOSTE] Corrigan-Gibbs, H., Boneh, D., and D. Mazières, "Riposte: An Anonymous Messaging System Handling Millions of Users", May 2015, <https://people.csail.mit.edu/henrycg/pubs/ oakland15riposte/>.
[Raposte] Corrigan-Gibbs、H.、Boneh、D.、D.Mazières、2015年5月、<https：//people.csail.mit.edu/henrycg <https：//people.csail.mit.edu/henrycg/ PUBS / OAKLAND15RIPOSTE />。
[TLS-SUBCERTS] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 2021, <https://tools.ietf.org/html/draft-ietf-tls-subcerts-10>.
[TLS-SUBCERTS] Barnes、R.、Iyengar、S.、Sullivan、N.、およびE. Rescorla、「TLSの代表資格情報」、進行中の作業、インターネットドラフト、草案-TLS-SUBCERTS-10、2021年1月24日、<https://tools.ietf.org/html/draft-ietf-tls-subcerts-10>。
[VIPR-OVERVIEW] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-Huguenin, "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Work in Progress, Internet-Draft, draft-jennings-vipr-overview-06, 9 December 2013, <https://tools.ietf.org/html/draft-jennings-vipr-overview-06>.
[VIPR-概要]バーンズ、M.、Jennings、C、C.、Rosenberg、J.、およびM.Pstit-Huguenin、「PSTN到達可能性に関する検証：要件と建築の概要」、進行中、インターネットドラフト、ドラフトジェニング-vipr-overview-06、2013年12月9日、<https://tools.ietf.org/html/draft-jennings-vipr-overview-06>。
Acknowledgments
謝辞
The ideas in this document came out of discussions with Richard Barnes and Cullen Jennings. We'd also like to thank Russ Housley, Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang, Jonathan Rosenberg, and Robert Sparks for helpful suggestions.
この文書のアイデアは、Richard BarnesとCullen Jenningsとの議論から出ました。Russ Housle、Chris Wendt、Eric Burger、Mary Barnes、Ben Campbell、Ted Huang、Jonathan Rosenberg、およびRobert Sparksが役立つ提案のためにもあります。
Authors' Addresses
著者の住所
Eric Rescorla Mozilla
Eric Rescorla Mozilla.
Email: ekr@rtfm.com
Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar、Inc。1800 Stuter St Suite 570 Concord、CA 94520アメリカ合衆国
Email: jon.peterson@team.neustar