[要約] RFC 7340は、セキュアな電話の識別の問題と要件に関するものであり、電話の信頼性とセキュリティを向上させるためのソリューションを提案しています。目的は、不正な電話の識別情報の悪用を防ぎ、通信の信頼性を確保することです。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 7340 NeuStar, Inc.
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
H. Tschofenig
September 2014
Secure Telephone Identity Problem Statement and Requirements
安全な電話アイデンティティ問題ステートメントと要件
Abstract
概要
Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.
過去10年間で、SIPに基づくVoice over IP（VoIP）システムは、多くの従来のテレフォニー展開に取って代わりました。 VoIPシステムと従来の電話ネットワークとのインターワーキングにより、大量の商用通話スキームのオーケストレーション、ボイスメールボックスのハッキング、または複数の迂回を行う際に、発信者番号を偽装または不明瞭にする新しい安価なツールを攻撃者に付与することにより、発信者番号および発信者IDの保証の全体的なレベルが低下しました銀行から信頼されている多要素認証システム。 SIP通信の発信元を安全に保証しようとする以前の試みにもかかわらず、VoIPセッションで発呼者を識別するための効果的な標準がまだありません。このドキュメントでは、インターネット上の電話番号にIDを提供することが困難である理由を検証し、過去10年間の変更により、SIPセッションに安全なIDをアタッチするための新しい戦略がどのように提供されるかを示します。また、この領域でのソリューションに対する高レベルの要件も提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7340.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7340で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Problem Statement ...............................................4
3. Terminology .....................................................6
4. Use Cases .......................................................6
4.1. VoIP-to-VoIP Call ..........................................7
4.2. VoIP-PSTN-VoIP Call ........................................7
4.3. PSTN-to-VoIP Call ..........................................8
4.4. VoIP-to-PSTN Call ..........................................9
4.5. PSTN-VoIP-PSTN Call .......................................10
4.6. PSTN-to-PSTN Call .........................................11
5. Limitations of Current Solutions ...............................11
5.1. P-Asserted-Identity .......................................12
5.2. SIP Identity ..............................................14
5.3. VIPR ......................................................17
6. Environmental Changes ..........................................19
6.1. Shift to Mobile Communication .............................19
6.2. Failure of Public ENUM ....................................19
6.3. Public Key Infrastructure Developments ....................20
6.4. Prevalence of B2BUA Deployments ...........................20
6.5. Stickiness of Deployed Infrastructure .....................20
6.6. Concerns about Pervasive Monitoring .......................21
6.7. Relationship with Number Assignment and Management ........21
7. Basic Requirements .............................................22
8. Acknowledgments ................................................23
9. Security Considerations ........................................23
10. Informative References ........................................23
In many communication architectures that allow users to communicate with other users, the need arises for identifying the originating party that initiates a call or a messaging interaction. The desire to identify communication parties in end-to-end communication derives from the need to implement authorization policies (to grant or reject call attempts) but has also been utilized for charging. While there are a number of ways to enable identification, this functionality has been provided by the Session Initiation Protocol (SIP) [RFC3261] by using two main types of approaches, namely, P-Asserted-Identity (PAI) [RFC3325] and SIP Identity [RFC4474], which are described in more detail in Section 5. The goal of these mechanisms is to validate that the originator of a call is authorized to claim an originating identifier. Protocols like the Extensible Messaging and Presence Protocol (XMPP) use mechanisms that are conceptually similar to those offered by SIP.
ユーザーが他のユーザーと通信することを可能にする多くの通信アーキテクチャーでは、通話またはメッセージング対話を開始する発信者を識別する必要があります。エンドツーエンドの通信で通信パーティを識別したいという欲求は、（コール試行を許可または拒否するための）許可ポリシーを実装する必要性から派生していますが、課金にも利用されています。識別を有効にする方法はいくつかありますが、この機能は、P-Asserted-Identity（PAI）[RFC3325]とSIPの2つの主要なタイプのアプローチを使用して、Session Initiation Protocol（SIP）[RFC3261]によって提供されています。アイデンティティ[RFC4474]。セクション5で詳しく説明します。これらのメカニズムの目的は、コールの発信者が発信者IDを要求することを承認されていることを検証することです。 Extensible Messaging and Presence Protocol（XMPP）のようなプロトコルは、SIPが提供するものと概念的に同様のメカニズムを使用します。
Although solutions have been standardized, it turns out that the current deployment situation is unsatisfactory, and even worse, there is little indication that it will improve in the future. In [SECURE-ORIGIN], we illustrate what challenges arise. In particular, interworking with different communication architectures (e.g., SIP, Public Switched Telephone Network (PSTN), XMPP, Real-Time Communications on the Web (RTCWeb)) or other forms of mediation breaks the end-to-end semantic of the communication interaction and destroys any identification capabilities. (In this document, we use the term "PSTN" colloquially rather than in a legal or policy sense, as a common shorthand for the circuit-switched analog and time-division multiplexing (TDM) digital telephone system, often using Signaling System #7 (SS7) to control call setup and teardown.) Furthermore, the use of different identifiers (e.g., E.164 numbers vs. SIP URIs) creates challenges for determining who is able to claim "ownership" for a specific identifier; although domain-based identifiers (sip:user@example.com) might use certificate or DNS-related approaches to determine who is able to claim "ownership" of the URI, telephone numbers do not yet have any similar mechanism defined.
ソリューションは標準化されていますが、現在の展開状況は不十分であり、さらに悪いことに、将来的に改善される兆候はほとんどありません。 [SECURE-ORIGIN]では、発生する課題を説明します。特に、さまざまな通信アーキテクチャ（SIP、公衆電話交換網（PSTN）、XMPP、Web上のリアルタイム通信（RTCWeb）など）または他の形式のメディエーションとの相互作用により、通信のエンドツーエンドのセマンティクスが壊れます相互作用し、識別機能を破壊します。 （このドキュメントでは、信号交換システム＃7をよく使用する回線交換アナログおよび時分割多重（TDM）デジタル電話システムの一般的な省略形として、法的またはポリシーの意味ではなく、口語的に「PSTN」という用語を使用します。 （SS7）コールのセットアップとティアダウンを制御します。）さらに、異なる識別子（E.164番号とSIP URIなど）を使用すると、特定の識別子の「所有権」を主張できる人を決定するための課題が生じます。ドメインベースの識別子（sip：user@example.com）は、証明書またはDNS関連のアプローチを使用して、誰がURIの「所有権」を主張できるかを決定しますが、電話番号にはまだ同様のメカニズムが定義されていません。
After the publication of the PAI and SIP Identity specifications ([RFC3325] and [RFC4474], respectively), further attempts have been made to tackle the topic but, unfortunately, with little success, due to the complexity of deploying solutions and the long list of (often conflicting) requirements. A number of years have passed since the last attempts were made to improve the situation, and we therefore believe it is time to give it another try. With this document, we would like to start to develop a common understanding of the problem statement as well as basic requirements to develop a vision on how to advance the state of the art and to initiate technical work to enable secure call origin identification.
PAIおよびSIP ID仕様（それぞれ[RFC3325]および[RFC4474]）の公開後、このトピックに取り組むためのさらなる試みが行われましたが、ソリューションの展開の複雑さと長いリストのため、残念ながらほとんど成功していません（しばしば矛盾する）要件の。状況を改善するための最後の試みが行われてから数年が経過しました。したがって、私たちはそれをもう一度試す時が来たと信じています。このドキュメントを使用して、問題のステートメントの一般的な理解と、最先端の技術を進歩させ、安全な発信元の識別を可能にするための技術的な作業を開始するためのビジョンを開発するための基本的な要件を開発し始めます。
In the classical Public Switched Telephone Network, there were a limited number of carriers, all of whom trusted each other to provide accurate caller origination information in an environment without any cryptographic validation. In some cases, national telecommunication regulation codified these obligations. This model worked as long as the number of entities was relatively small, easily identified (e.g., in the manner carriers are certified in the United States), and subject to effective legal sanctions in case of misbehavior. However, for some time, these assumptions have no longer held true. For example, entities that are not traditional telecommunication carriers, possibly located outside the country whose country code they are using, can act as voice service providers. While there was a clear distinction between customers and service providers in the past, VoIP service providers can now easily act as customers or either originating or transit providers. Moreover, the problem is not limited to voice communications, as growth in text messaging has made it another vector for bulk unsolicited commercial messaging relying on impersonation of a source telephone number or, sometimes, an SMS short code. For telephony, Caller ID spoofing has become common, with a small subset of entities either ignoring abuse of their services or willingly serving to enable fraud and other illegal behavior.
従来の公衆交換電話網では、限られた数のキャリアがあり、そのすべてが互いに暗号化された検証のない環境で正確な発信者の発信情報を提供すると互いに信頼していました。場合によっては、国内の電気通信規制がこれらの義務を成文化しました。このモデルは、エンティティの数が比較的少なく、識別が容易（たとえば、米国でキャリアが認定されている方法）であり、不正行為が発生した場合に効果的な法的制裁の対象となる限り機能しました。ただし、しばらくの間、これらの仮定はもはや成り立たなくなりました。たとえば、従来の電気通信事業者ではないエンティティは、おそらく国コードが使用されている国の外にあり、音声サービスプロバイダーとして機能できます。過去には顧客とサービスプロバイダーの間に明確な違いがありましたが、VoIPサービスプロバイダーは、顧客として、または発信プロバイダーまたはトランジットプロバイダーとして簡単に機能できるようになりました。さらに、問題は音声通信に限定されず、テキストメッセージングの増加により、発信元の電話番号またはSMSショートコードのなりすましに依存する大量の迷惑な商用メッセージングのもう1つのベクトルになりました。電話の場合、発信者IDのなりすましが一般的になり、エンティティの小さなサブセットがサービスの悪用を無視するか、または意図的に詐欺やその他の違法行為を可能にします。
For example, recently, enterprises and public safety organizations have been subjected to telephony denial-of-service attacks [TDOS]. In this case, an individual claiming to represent a collections company for payday loans starts the extortion scheme with a phone call to an organization. Failing to get payment from an individual or organization, the criminal organization launches a barrage of phone calls with spoofed numbers, preventing the targeted organization from receiving legitimate phone calls. Other boiler-room organizations use number spoofing to place illegal "robocalls" (automated telemarketing; see, for example, the US Federal Communications Commission webpage on this topic [ROBOCALL-FCC]). Robocalls are a problem that has been recognized already by various regulators; for example, the US Federal Trade Commission (FTC) recently organized a robocall competition to solicit ideas for creating solutions that will block illegal robocalls [ROBOCALL-CHALLENGE]. Criminals may also use number spoofing to impersonate banks or bank customers to gain access to information or financial accounts.
たとえば、最近、企業や公安機関が電話サービス拒否攻撃[TDOS]を受けています。この場合、ペイデイローンの回収会社を代表すると主張する個人は、組織への電話で恐喝スキームを開始します。個人または組織から支払いを受け取れなかった犯罪組織は、なりすまし番号を使って大量の電話をかけ、標的となる組織が正当な電話を受けられないようにします。他のボイラー室組織は、番号のなりすましを使用して違法な「ロボコール」を発信しています（自動テレマーケティング、たとえば、このトピックに関する米国連邦通信委員会のWebページ[ROBOCALL-FCC]を参照）。ロボコールは、さまざまな規制当局によってすでに認識されている問題です。たとえば、米国連邦取引委員会（FTC）は最近、違法なロボコールをブロックするソリューションを作成するためのアイデアを募るためにロボコール競争を組織しました[ROBOCALL-CHALLENGE]。犯罪者は、銀行や銀行の顧客になりすまして情報や金融口座にアクセスするために、番号のなりすましを使用することもあります。
In general, number spoofing is used in two ways: impersonation and anonymization. For impersonation, the attacker pretends to be a specific individual. Impersonation can be used for pretexting, where the attacker obtains information about the individual impersonated and, for example, activates credit cards, or for harassment, e.g., causing utility services to be disconnected, take-out food to be delivered, or police to respond to a non-existing hostage situation ("swatting"; see [SWATTING]). Some voicemail systems can be set up so that they grant access to stored messages without a password, relying solely on the caller identity. As an example, in the News International phone-hacking scandal [NEWS-HACK], employees of the newspaper were accused of engaging in phone hacking by utilizing Caller ID spoofing to get access to voicemail. For numbers where the caller has suppressed textual caller identification, number spoofing can be used to retrieve this information, stored in the so-called Calling Name (CNAM) database. For anonymization, the caller does not necessarily care whether the number is in service or who it is assigned to and may switch rapidly and possibly randomly between numbers. Anonymization facilitates automated illegal telemarketing or telephony denial-of-service attacks, as described above, as it makes it difficult to identify perpetrators and craft policies to block them. It also makes tracing such calls much more labor-intensive, as each call has to be identified in each transit carrier hop-by-hop, based on destination number and time of call.
一般に、番号のなりすましは、なりすましと匿名化の2つの方法で使用されます。なりすましの場合、攻撃者は特定の個人を装います。なりすましは、なりすましを使用して、なりすましの対象となる個人に関する情報を攻撃者が取得し、たとえばクレジットカードをアクティブ化する場合や、嫌がらせ（ユーティリティサービスの接続を切断する、食品を持ち帰る、警察が対応するなど）に使用できます。存在しない人質の状況へ（ "スワッティング"; [SWATTING]を参照）。一部のボイスメールシステムは、発信者のIDのみに依存して、パスワードなしで保存されたメッセージへのアクセスを許可するように設定できます。例として、ニュースインターナショナルの電話ハッキングスキャンダル[NEWS-HACK]で、新聞の従業員は、発信者IDのなりすましを利用してボイスメールにアクセスし、電話ハッキングに従事したとして告発されました。発信者がテキストの発信者識別を抑制した番号の場合、番号のなりすましを使用してこの情報を取得できます。この情報は、いわゆる発信者名（CNAM）データベースに格納されています。匿名化の場合、発信者は番号が使用中かどうか、または割り当て先を必ずしも気にする必要はなく、番号間で急速に、場合によってはランダムに切り替わることがあります。匿名化は、前述のように、自動化された違法なテレマーケティングまたはテレフォニーのサービス拒否攻撃を容易にします。これは、加害者を特定し、それらをブロックするポリシーを作成することを困難にするためです。また、各通話は、宛先番号と通話時間に基づいて、ホップごとに各トランジットキャリアで識別される必要があるため、このような通話の追跡にはるかに手間がかかります。
It is insufficient to simply outlaw all spoofing of originating telephone numbers because the entities spoofing numbers are already committing other crimes and are thus unlikely to be deterred by legal sanctions. Secure origin identification should prevent impersonation and, to a lesser extent, anonymization. However, if numbers are easy and cheap to obtain, and if the organizations assigning identifiers cannot or will not establish the true corporate or individual identity of the entity requesting such identifiers, robocallers will still be able to switch between many different identities.
発信元の電話番号のすべてのなりすましを単に非合法化するだけでは不十分です。これは、なりすましのエンティティがすでに他の犯罪を犯しており、したがって法的制裁によって抑止される可能性が低いためです。安全な出所の特定は、なりすましを防ぎ、程度は低いものの匿名化を防ぐ必要があります。ただし、番号を取得するのが簡単で安価であり、識別子を割り当てる組織が、そのような識別子を要求するエンティティの真の企業IDまたは個人IDを確立できない場合、または確立しない場合でも、ロボコーラーは多くの異なるIDを切り替えることができます。
The problem space is further complicated by a number of use cases where entities in the telephone network legitimately send calls on behalf of others, including "Find-Me/Follow-Me" services. Ultimately, any SIP entity can receive an INVITE request and forward it to any other entity, and the recipient of a forwarded message has little means to ascertain which recipient a call should legitimately target (see [SIP-SECURITY]). Also, in some cases, third parties may
「Find-Me / Follow-Me」サービスなど、電話ネットワークのエンティティが他のユーザーに代わって合法的に通話を送信する多くの使用例により、問題の領域はさらに複雑になります。最終的には、SIPエンティティはINVITE要求を受信して他のエンティティに転送できます。転送されたメッセージの受信者は、コールが正当に対象とする受信者を確認する手段がほとんどありません（[SIP-SECURITY]を参照）。また、場合によっては、第三者が
need to temporarily use the identity of another individual or organization with full consent of the "owner" of the identifier. For example:
識別子の「所有者」の完全な同意を得て、一時的に別の個人または組織のIDを使用する必要がある。例えば：
Doctors' offices: Physicians calling their patients using their cell phones would like to replace their mobile phone number with the number of their office to avoid being called back by patients on their personal phone.
医師のオフィス：携帯電話を使用して患者に電話をかける医師は、携帯電話番号を自分のオフィスの番号に置き換えて、個人用電話で患者がかけ直されないようにします。
Call centers: Call centers operate on behalf of companies, and the called party expects to see the Caller ID of the company, not the call center.
コールセンター：コールセンターは会社に代わって動作し、着信側はコールセンターではなく会社の発信者IDを確認することを期待しています。
The following terms are defined in this document:
このドキュメントでは、次の用語が定義されています。
In-band Identity Conveyance: In-band conveyance is the presence of call origin identification information conveyed within the control plane protocol(s) setting up a call. Any in-band solution must accommodate in-band intermediaries such as Back-to-Back User Agents (B2BUAs).
帯域内ID伝達：帯域内伝達は、呼び出しを設定するコントロールプレーンプロトコル内で伝達される発信元識別情報の存在です。インバンドソリューションは、バックツーバックユーザーエージェント（B2BUA）などのインバンド仲介者に対応する必要があります。
Out-of-Band Identity Verification: Out-of-band verification determines whether the telephone number used by the calling party actually exists, whether the calling entity is entitled to use the number, and whether a call has recently been made from this phone number. This approach is needed because the in-band technique does not work in all cases, as when certain intermediaries are involved or due to interworking with circuit-switched networks.
帯域外ID検証：帯域外検証は、発呼者が使用する電話番号が実際に存在するかどうか、発呼者がその番号を使用する資格があるかどうか、およびこの電話番号から最近通話が行われたかどうかを決定します。特定の仲介者が関与している場合や、回線交換ネットワークとの相互接続が原因である場合など、インバンド手法がすべてのケースで機能するわけではないため、このアプローチが必要です。
Authority Delegation Infrastructure: The delegation authority infrastructure determines how the authority over telephone numbers is used when numbers are ported and delegated. It also describes how the existing numbering infrastructure is reused to maintain the lifecycle of number assignments.
権限委譲インフラストラクチャ：委任権限インフラストラクチャは、番号が移植および委任されるときに電話番号に対する権限がどのように使用されるかを決定します。また、既存の番号付けインフラストラクチャを再利用して、番号割り当てのライフサイクルを維持する方法についても説明します。
Canonical Telephone Number: In order for either in-band conveyance or out-of-band verification to work, entities must be able to canonicalize telephone numbers to arrive at a common syntactical form.
正規の電話番号：帯域内伝達または帯域外検証が機能するためには、エンティティが電話番号を正規化して、共通の構文形式に到達できる必要があります。
In order to explain the requirements and other design assumptions, we will explain some of the scenarios that need to be supported by any solution. To reduce clutter, the figures do not show call-routing elements such as SIP proxies of voice or text service providers. We generally assume that the PSTN component of any call path cannot be altered.
要件とその他の設計の前提条件を説明するために、ソリューションでサポートする必要があるいくつかのシナリオについて説明します。煩雑さを減らすために、図では音声またはテキストサービスプロバイダーのSIPプロキシなどのコールルーティング要素は示していません。通常、コールパスのPSTNコンポーネントは変更できないと想定しています。
For the VoIP-to-VoIP communication case, a group of service providers that offer interconnected VoIP service exchange calls using SIP end-to-end but may also deliver some calls via circuit-switched facilities, as described in separate use cases below. These service providers use telephone numbers as source and destination identifiers, either as the user component of a SIP URI (e.g., sip:12125551234@example.com) or as a tel URI [RFC3966].
VoIP間通信の場合、相互接続されたVoIPサービスを提供するサービスプロバイダーのグループは、SIPエンドツーエンドを使用して通話を交換しますが、以下の別の使用例で説明するように、回線交換ファシリティを介して一部の通話を配信する場合もあります。これらのサービスプロバイダーは、SIP URIのユーザーコンポーネント（sip：12125551234@example.comなど）またはtel URI [RFC3966]のいずれかとして、電話番号を送信元および宛先の識別子として使用します。
As illustrated in Figure 1, if Alice calls Bob, the call will use SIP end-to-end. (The call may or may not traverse the Internet.)
図1に示すように、アリスがボブに電話をかけると、通話はSIPエンドツーエンドを使用します。 （呼び出しはインターネットを通過する場合と通過しない場合があります。）
+------------+
| IP-based |
| SIP Phone |<--+
| of Bob | |
|+19175551234| |
+------------+ |
|
+------------+ |
| IP-based | |
| SIP Phone | ------------
| of Alice | / | \
|+12121234567| // | \\
+------------+ // ,' \\\
| /// / -----
| //// ,' \\\\
| / ,' \
| | ,' |
+---->|......: IP-based |
| Network |
\ /
\\\\ ////
-------------------------
Figure 1: VoIP-to-VoIP Call
ふぃぐれ １： ゔぉいＰーとーゔぉいＰ かっｌ
Frequently, two VoIP-based service providers are not directly connected by VoIP and use Time Division Multiplexer (TDM) circuits to exchange calls, leading to the IP-PSTN-IP use case. In this use case, Dan's Voice Service Provider (VSP) is not a member of the interconnect federation Alice's and Bob's VSP belongs to. As far as Alice is concerned, Dan is not accessible via IP, and the PSTN is used as an interconnection network. Figure 2 shows the resulting exchange.
多くの場合、2つのVoIPベースのサービスプロバイダーはVoIPによって直接接続されておらず、時分割多重（TDM）回線を使用して通話を交換しているため、IP-PSTN-IPの使用例につながります。このユースケースでは、Danの音声サービスプロバイダー（VSP）は、AliceとBobのVSPが属する相互接続フェデレーションのメンバーではありません。アリスに関する限り、ダンはIP経由でアクセスできず、PSTNは相互接続ネットワークとして使用されます。図2は、結果の交換を示しています。
--------
//// \\\\
+--- >| PSTN |
| | |
| \\\\ ////
| --------
| |
| |
| |
+------------+ +--+----+ |
| IP-based | | PSTN | |
| SIP Phone | --+ VoIP +- v
| of Alice | / | GW | \ +---+---+
|+12121234567| // `''''''' \\| PSTN |
+------------+ // | \+ VoIP +
| /// | | GW |\
| //// | `'''''''\\ +------------+
| / | | \ | IP-based |
| | | | | | Phone |
+---->|---------------+ +------|---->| of Dan |
| | |+12039994321|
\ IP-based / +------------+
\\\\ Network ////
-------------------------
Figure 2: IP-PSTN-IP Call
図2：IP-PSTN-IPコール
Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that looks similar to this scenario since the original call content would, in the worst case, be re-created on the call origination side.
注：B2BUA /セッションボーダーコントローラー（SBC）は、元の通話コンテンツが最悪の場合、発信側で再作成されるため、このシナリオに似た動作を示します。
Consider Figure 3, where Carl is using a PSTN phone and initiates a call to Alice. Alice is using a VoIP-based phone. The call from Carl traverses the PSTN and enters the Internet via a PSTN/VoIP gateway. This gateway attaches some identity information to the call, for example, based on the caller identification information it had received through the PSTN, if available.
カールがPSTN電話を使用していて、アリスへの通話を開始している図3を検討してください。アリスはVoIPベースの電話を使用しています。 CarlからのコールはPSTNを通過し、PSTN / VoIPゲートウェイ経由でインターネットに入ります。このゲートウェイは、たとえば、PSTNを介して受信した発信者の識別情報（利用可能な場合）に基づいて、いくつかのID情報を呼び出しに添付します。
--------
//// \\\\
+->| PSTN |--+
| | | |
| \\\\ //// |
| -------- |
| |
| v
| +----+-------+
+---+------+ |PSTN / VoIP | +-----+
|PSTN Phone| |Gateway | |SIP |
|of Carl | +----+-------+ |UA |
+----------+ | |Alice|
INVITE +-----+
| ^
V |
+---------------+ INVITE
|VoIP | |
|Interconnection| INVITE +-------+
|Provider(s) |----------->+ |
+---------------+ |Alice's|
|VSP |
| |
+-------+
Figure 3: PSTN-to-VoIP Call
ふぃぐれ ３： ＰＳＴんーとーゔぉいＰ かっｌ
Consider Figure 4, where Alice calls Carl. Carl uses a PSTN phone, and Alice uses an IP-based phone. When Alice initiates the call, the E.164 number is translated to a SIP URI and subsequently to an IP address. The call of Alice traverses her VoIP provider, where the call origin identification information is added. It then hits the PSTN/VoIP gateway. It is desirable that the gateway verify that Alice can claim the E.164 number she is using before it populates the corresponding calling party number field in telephone network signaling. Carl's phone must be able to verify that it is receiving a legitimate call from the calling party number it will render to Carl.
アリスがカールに電話をかけている図4を検討してください。カールはPSTN電話を使用し、アリスはIPベースの電話を使用します。 Aliceが通話を開始すると、E.164番号がSIP URIに変換され、続いてIPアドレスに変換されます。アリスのコールは彼女のVoIPプロバイダーを通過し、そこでコールの発信元識別情報が追加されます。その後、PSTN / VoIPゲートウェイに到達します。ゲートウェイは、アリスが電話網シグナリングの対応する発呼者番号フィールドに入力する前に、アリスが使用しているE.164番号を要求できることを確認することが望ましい。カールの電話は、カールにレンダリングする発信者番号から正当な呼び出しを受信していることを確認できる必要があります。
+-------+ +-----+ -C
|PSTN | |SIP | |a
|Phone |<----------------+ |UA | |l
|of Carl| | |Alice| |l
+-------+ | +-----+ |i
--------------------------- | |n
//// \\\\ | |g
| PSTN | INVITE |
| | | |P
\\\\ //// | |a
--------------------------- | |r
^ | |t
| v |y
+------------+ +--------+|
|PSTN / VoIP |<--INVITE----|VoIP ||D
|Gateway | |Service ||o
+------------+ |Provider||m
|of Alice||a
+--------+|i
-n
Figure 4: VoIP-to-PSTN Call
ふぃぐれ ４： ゔぉいＰーとーＰＳＴん かっｌ
Consider Figure 5, where Carl calls Alice. Both users have PSTN phones, but interconnection between the two circuit-switched parts of the PSTN is accomplished via an IP network. Consequently, Carl's operator uses a PSTN-to-VoIP gateway to route the call via an IP network to a gateway to break out into the PSTN again.
カールがアリスに電話する図5を考えてみましょう。どちらのユーザーもPSTN電話を持っていますが、PSTNの2つの回線交換部分間の相互接続はIPネットワークを介して行われます。その結果、Carlのオペレーターは、PSTNからVoIPへのゲートウェイを使用して、IPネットワーク経由でゲートウェイにコールをルーティングし、PSTNに再度発信します。
+----------+
|PSTN Phone|
-------- |of Alice |
//// \\\\ +----------+
+->| PSTN |------+ ^
| | | | |
| \\\\ //// | |
| -------- | --------
| v //// \\\\
| ,-------+ | PSTN |
| |PSTN | | |
+---+------+ __|VoIP GW|_ \\\\ ////
|PSTN Phone| / '`''''''' \ --------
|of Carl | // | \\ ^
+----------+ // | \\\ |
/// -. INVITE ----- |
//// `-. \\\\ |
/ `.. \ |
| IP-based `._ ,--+----+
| Network `.....>|VoIP |
| |PSTN GW|
\ '`'''''''
\\\\ ////
-------------------------
Figure 5: PSTN-VoIP-PSTN Call
図5：PSTN-VoIP-PSTNコール
For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond improvement, we may be able to use out-of-band IP connectivity at both the originating and terminating carrier to validate the call information.
PSTNからPSTNへのコールの「レガシー」ケースの場合、それ以外の場合は改善を超えて、発信側キャリアと終端側キャリアの両方で帯域外IP接続を使用して、コール情報を検証できる場合があります。
From the inception of SIP, the From header field value has held an arbitrary user-supplied identity, much like the From header field value of an SMTP email message. During work on [RFC3261], efforts began to provide a secure origin for SIP requests as an extension to SIP. The so-called "short term" solution, the P-Asserted-Identity header described in [RFC3325], is deployed fairly widely, even though it is limited to closed trusted networks where end-user devices cannot alter or inspect SIP messages and offers no cryptographic validation. As P-Asserted-Identity is used increasingly across multiple networks, it cannot offer any protection against identity spoofing by intermediaries or entities that allow untrusted entities to set the P-Asserted-Identity information. An overview of addressing spam in SIP and an explanation of how it differs from similar problems with email appeared in [RFC5039].
SIPの最初から、Fromヘッダーフィールド値は、SMTP電子メールメッセージのFromヘッダーフィールド値と同様に、ユーザーが指定した任意のIDを保持しています。 [RFC3261]の作業中に、SIPの拡張としてSIPリクエストの安全なオリジンを提供する取り組みが始まりました。いわゆる「短期」ソリューションである[RFC3325]で説明されているP-Asserted-Identityヘッダーは、エンドユーザーのデバイスがSIPメッセージを変更または検査できない閉じた信頼できるネットワークに限定されているにもかかわらず、かなり広く展開されています暗号の検証はありません。 P-Asserted-Identityが複数のネットワークでますます使用されるようになると、信頼できないエンティティがP-Asserted-Identity情報を設定できるようにする仲介者またはエンティティによるIDスプーフィングに対する保護を提供できなくなります。 SIPでのスパムへの対処の概要と、電子メールの同様の問題との違いの説明は、[RFC5039]に掲載されています。
Subsequent efforts to prevent calling-origin identity spoofing in SIP include the SIP Identity effort (the "long-term" identity solution) [RFC4474] and Verification Involving PSTN Reachability (VIPR) [VIPR-OVERVIEW]. SIP Identity attaches a new header field to SIP requests containing a signature over the From header field value combined with other message components to prevent replay attacks. SIP Identity is meant to prevent both (a) SIP UAs from originating calls with spoofed From headers and (b) intermediaries, such as SIP proxies, from launching man-in-the-middle attacks by altering calls as they pass through the intermediaries. The VIPR architecture attacked a broader range of problems relating to spam, routing, and identity with a new infrastructure for managing rendezvous and security, which operated alongside of SIP deployments.
SIPでの発信元IDスプーフィングを防止するための後続の取り組みには、SIP Identity取り組み（「長期」IDソリューション）[RFC4474]およびPSTN到達可能性を含む検証（VIPR）[VIPR-OVERVIEW]が含まれます。 SIP IDは、リプレイ攻撃を防ぐために、他のメッセージコンポーネントと組み合わされたFromヘッダーフィールド値に対する署名を含むSIPリクエストに新しいヘッダーフィールドを添付します。 SIP IDは、（a）SIP UAがスプーフィングされたFromヘッダーを使用してコールを発信すること、および（b）SIPプロキシなどの仲介者が、仲介者を通過するときにコールを変更することによって中間者攻撃を開始することを防ぐことを目的としています。 VIPRアーキテクチャは、ランデブーとセキュリティを管理するための新しいインフラストラクチャを使用して、スパム、ルーティング、IDに関連する幅広い問題を攻撃しました。
As we will describe in more detail below, both SIP Identity and VIPR suffer from serious limitations that have prevented their deployment on a significant scale, but they may still offer ideas and protocol building blocks for a solution.
以下でより詳細に説明するように、SIP IdentityとVIPRの両方は、大規模な展開を妨げる深刻な制限に悩まされていますが、ソリューションのアイデアとプロトコル構築ブロックを提供する可能性があります。
The P-Asserted-Identity header field of SIP [RFC3325] provides a way for trusted network entities to share with one another an authoritative identifier for the originator of a call. The value of P-Asserted-Identity cannot be populated by a user, though if a user wants to suggest an identity to the trusted network, a separate header (P-Preferred-Identity) enables them to do so. The features of the P-Asserted-Identity header evolved as part of a broader effort to reach parity with traditional telephone network signaling mechanisms for selectively sharing and restricting presentation of the calling party number at the user level while still allowing core network elements to know the identity of the user for abuse prevention and accounting.
SIP [RFC3325]のP-Asserted-Identityヘッダーフィールドは、信頼できるネットワークエンティティが通話の発信者の信頼できる識別子を互いに共有する方法を提供します。 P-Asserted-Identityの値をユーザーが入力することはできませんが、ユーザーが信頼できるネットワークにIDを提案したい場合は、別のヘッダー（P-Preferred-Identity）を使用してそれを行うことができます。 P-Asserted-Identityヘッダーの機能は、コアネットワークエレメントが引き続きコアネットワーク要素を認識できるようにしながら、ユーザーレベルで発呼者番号の提示を選択的に共有および制限するための従来の電話ネットワークシグナリングメカニズムと同等になる幅広い取り組みの一環として進化しました虐待防止と会計のためのユーザーのアイデンティティ。
In order for P-Asserted-Identity to have these properties, it requires the existence of a trust domain as described in [RFC3324]. Any entity in the trust domain may add a P-Asserted-Identity header to a SIP message, and any entity in the trust domain may forward a message with a P-Asserted-Identity header to any other entity in the trust domain. If a trusted entity forwards a SIP request to an untrusted entity, however, the P-Asserted-Identity header must first be removed; most end-user devices are outside trust domains. Sending a P-Asserted-Identity request to an untrusted entity could leak potentially private information, such as the network-asserted calling party number in a case where a caller has requested presentation restriction. This concept of a trust domain is modeled on the trusted network of devices that operate the traditional telephone network.
P-Asserted-Identityにこれらのプロパティを持たせるには、[RFC3324]で説明されているように、信頼ドメインが存在する必要があります。信頼ドメイン内のエンティティは、P-Asserted-IdentityヘッダーをSIPメッセージに追加できます。信頼ドメイン内のエンティティは、P-Asserted-Identityヘッダーを含むメッセージを信頼ドメイン内の他のエンティティに転送できます。ただし、信頼できるエンティティが信頼できないエンティティにSIP要求を転送する場合、最初にP-Asserted-Identityヘッダーを削除する必要があります。ほとんどのエンドユーザーデバイスは信頼ドメインの外部にあります。信頼できないエンティティにP-Asserted-Identityリクエストを送信すると、発信者が表示制限をリクエストした場合に、ネットワークアサートされた発呼者番号などの潜在的なプライベート情報が漏洩する可能性があります。信頼ドメインのこの概念は、従来の電話ネットワークを操作するデバイスの信頼されたネットワークをモデルにしています。
P-Asserted-Identity has been very successful in telephone replacement deployments of SIP. It is an extremely simple in-band mechanism, requiring no cryptographic operations. Since it is so reminiscent of legacy mechanisms in the traditional telephone network and interworks so seamlessly with those protocols, it has naturally been favored by providers comfortable with these operating principles.
P-Asserted-Identityは、SIPの電話交換配置で非常に成功しています。これは非常にシンプルなインバンドメカニズムで、暗号化操作は必要ありません。従来の電話ネットワークのレガシーメカニズムを彷彿とさせ、これらのプロトコルと非常にシームレスに相互作用するため、これらの動作原理に慣れているプロバイダーには当然のこととして好まれてきました。
In practice, a trust domain exhibits many of the same merits and flaws as the traditional telephone network when it comes to securing a calling party number. Any trusted entity may provide P-Asserted-Identity, and a recipient of a SIP message has no direct assurance of who generated the P-Asserted-Identity header field value: all trust is transitive. Trust domains are dictated by business arrangements more than by security standards; thus, the level of assurance of P-Asserted-Identity is only as good as the least trustworthy member of a trust domain. Since the contents of P-Asserted-Identity are not intended for consumption by end users, end users must trust that their service provider participates in an appropriate trust domain, as there will be no direct evidence of the trust domain in the SIP signaling that end-user devices receive. Since the mechanism is so closely modeled on the traditional telephone network, it is unlikely to provide a higher level of security than that.
実際には、信頼ドメインは、発呼者番号の保護に関して、従来の電話ネットワークと同じメリットと欠陥の多くを示します。信頼できるエンティティはP-Asserted-Identityを提供でき、SIPメッセージの受信者は、誰がP-Asserted-Identityヘッダーフィールド値を生成したかを直接保証しません。すべての信頼は推移的です。信頼ドメインは、セキュリティ基準よりもビジネスの取り決めによって決まります。したがって、P-Asserted-Identityの保証レベルは、信頼ドメインの最も信頼できないメンバーと同じくらい良好です。 P-Asserted-Identityのコンテンツはエンドユーザーによる消費を目的としていないため、エンドユーザーは、サービスプロバイダーが適切な信頼ドメインに参加していることを信頼する必要があります。 -ユーザーデバイスが受け取ります。このメカニズムは従来の電話ネットワークで非常に綿密にモデル化されているため、それよりも高いレベルのセキュリティを提供することはほとんどありません。
Since [RFC3325] was written, the whole notion of "P-" headers intended for use in private SIP domains has also been deprecated (see [RFC5727]) largely because of overwhelming evidence that these headers were being used outside of private contexts and leaking into the public Internet. It is unclear how many deployments that make use of P-Asserted-Identity in fact conform to the Spec(T) requirements of [RFC3324].
[RFC3325]が作成されてから、プライベートSIPドメインでの使用を目的とした「P-」ヘッダーの概念全体も非推奨になりました（[RFC5727]を参照）。これらのヘッダーがプライベートコンテキストの外部で使用され、リークしているという証拠が多かったためです。公共のインターネットに。 P-Asserted-Identityを使用するデプロイメントの数が、実際に[RFC3324]のSpec（T）要件に準拠していることは不明です。
P-Asserted-Identity also complicates the question of which URI should be presented to a user when a call is received. Per [RFC3261], SIP user agents would render the contents of the From header field to a user when receiving an INVITE request, but what if the P-Asserted-Identity contains a more trustworthy URI, and presentation is not restricted? Subsequent proposals have suggested additional header fields to carry different forms of identity related to the caller, including billing identities. As the calling identities in a SIP request proliferate, the question of how to select one to render to the end user becomes more difficult to answer.
P-Asserted-Identityは、呼び出しを受信したときにユーザーにどのURIを提示するかという問題も複雑にします。 [RFC3261]に従い、SIPユーザーエージェントはINVITEリクエストを受信するとFromヘッダーフィールドの内容をユーザーに表示しますが、P-Asserted-Identityに信頼できるURIが含まれていて、表示が制限されていない場合はどうなりますか？その後の提案では、請求IDを含む、発信者に関連するさまざまな形式のIDを伝送するための追加のヘッダーフィールドが提案されています。 SIPリクエストの呼び出しIDが急増すると、エンドユーザーに提供するIDをどのように選択するかという質問への回答が難しくなります。
The SIP Identity mechanism [RFC4474] provides two header fields for securing identity information in SIP requests: the Identity and Identity-Info header fields. Architecturally, the SIP Identity mechanism assumes a classic "SIP trapezoid" deployment in which an authentication service, acting on behalf of the originator of a SIP request, attaches identity information to the request that provides partial integrity protection; a verification service acting on behalf of the recipient validates the integrity of the request when it is received.
SIP IDメカニズム[RFC4474]は、SIPリクエストのID情報を保護するための2つのヘッダーフィールド、IdentityおよびIdentity-Infoヘッダーフィールドを提供します。アーキテクチャ上、SIP IDメカニズムは、SIPリクエストの発信者に代わって動作する認証サービスがID情報をリクエストに添付して部分的な完全性保護を提供する、クラシックな「SIP台形」展開を想定しています。受信者に代わって機能する検証サービスは、受信時に要求の整合性を検証します。
The Identity header field value contains a signature over a hash of selected elements of a SIP request, including several header field values (most significantly, the From header field value) and the entirety of the body of the request. The set of header field values was chosen specifically to prevent cut-and-paste attacks; it requires the verification service to retain some state to guard against replays. The signature over the body of a request has different properties for different SIP methods, but all prevent tampering by man-in-the-middle attacks. For a SIP MESSAGE request, for example, the signature over the body covers the actual message conveyed by the request: it is pointless to guarantee the source of a request if a man in the middle can change the content of the message, as in that case the message content is created by an attacker. Similar threats exist against the SIP NOTIFY method. For a SIP INVITE request, a signature over the Session Description Protocol (SDP) body is intended to prevent a man in the middle from changing properties of the media stream, including the IP address and port to which media should be sent, as this provides a means for the man in the middle to direct session media to a resource that the originator did not specify and thus impersonate an intended listener.
Identityヘッダーフィールド値には、いくつかのヘッダーフィールド値（最も重要なのはFromヘッダーフィールド値）と要求の本文全体を含む、SIP要求の選択された要素のハッシュに対する署名が含まれています。ヘッダーフィールド値のセットは、カットアンドペースト攻撃を防ぐために特別に選択されました。検証サービスは、リプレイから保護するためにいくつかの状態を保持する必要があります。リクエストの本文の署名には、SIPメソッドごとに異なるプロパティがありますが、すべて中間者攻撃による改ざんを防ぎます。たとえば、SIP MESSAGEリクエストの場合、本文のシグネチャは、リクエストによって伝達される実際のメッセージをカバーします。途中の人がメッセージの内容を変更できる場合、リクエストのソースを保証しても意味がありません。メッセージの内容が攻撃者によって作成された場合。 SIP NOTIFYメソッドに対して同様の脅威が存在します。 SIP INVITE要求の場合、Session Description Protocol（SDP）本体の署名は、メディアの送信先となるIPアドレスやポートなど、メディアストリームのプロパティを途中で変更できないようにすることを目的としています。途中の男がセッションメディアを発信者が指定していないリソースに向け、意図したリスナーになりすますための手段。
The Identity-Info header field value contains a URI designating the location of the certificate corresponding to the private key that signed the hash in the Identity header. That certificate could be passed by-value along with the SIP request, in which case a cid URI appears in Identity-Info, or by-reference, for example, when the Identity-Info header field value has the URL of a service that delivers the certificate. [RFC4474] imposes further constraints governing the subject of that certificate, namely, that it must cover the domain name indicated in the domain component of the URI in the From header field value of the request.
Identity-Infoヘッダーフィールド値には、Identityヘッダーのハッシュに署名した秘密キーに対応する証明書の場所を指定するURIが含まれています。その証明書は、SIPリクエストとともに値渡しすることができます。その場合、cid URIはIdentity-Infoに表示されます。または、たとえば、Identity-Infoヘッダーフィールド値に配信するサービスのURLがある場合、参照渡しします。証明書。 [RFC4474]は、その証明書のサブジェクトを管理する追加の制約を課します。つまり、要求のFromヘッダーフィールド値のURIのドメインコンポーネントに示されているドメイン名をカバーする必要があります。
The SIP Identity mechanism, however, has two fundamental limitations that have precluded its deployment: first, it provides identity only for domain names rather than other identifiers, and second, it does not tolerate intermediaries that alter the bodies, or certain header fields, of SIP requests.
ただし、SIP IDメカニズムには2つの基本的な制限があり、その導入は不可能でした。1つ目は、他の識別子ではなくドメイン名のみにIDを提供すること、もう1つは、本文または特定のヘッダーフィールドを変更する中間体を許容しないことです。 SIPリクエスト。
As deployed, SIP predominantly mimics the structures of the telephone network and thus uses telephone numbers as identifiers. Telephone numbers in the From header field value of a SIP request may appear as the user part of a SIP URI or, alternatively, in an independent tel URI. The certificate designated by the Identity-Info header field as specified, however, corresponds only to the domain portion of a SIP URI in the From header field. As such, [RFC4474] does not have any provision to identify the assignee of a telephone number. While it could be the case that the domain name portion of a SIP URI signifies a carrier (like "att.com") to whom numbers are assigned, the SIP Identity mechanism provides no assurance that a particular number has been assigned to any specific carrier. For a tel URI, moreover, it is unclear in [RFC4474] what entity should hold a corresponding certificate. A caller may not want to reveal the identity of its service provider to the callee and may thus prefer tel URIs in the From header field.
展開すると、SIPは主に電話ネットワークの構造を模倣するため、電話番号を識別子として使用します。 SIPリクエストのFromヘッダーフィールド値の電話番号は、SIP URIのユーザー部分として表示される場合と、代わりに独立したtel URIとして表示される場合があります。ただし、指定されたIdentity-Infoヘッダーフィールドで指定された証明書は、FromヘッダーフィールドのSIP URIのドメイン部分にのみ対応します。そのため、[RFC4474]には、電話番号の譲受人を識別するための規定がありません。 SIP URIのドメイン名部分が番号が割り当てられているキャリア（「att.com」など）を表す場合もありますが、SIP IDメカニズムは、特定の番号が特定のキャリアに割り当てられていることを保証しません。さらに、tel URIの場合、[RFC4474]では対応する証明書を保持する必要があるエンティティが明確ではありません。呼び出し元は、サービスプロバイダーのIDを呼び出し先に明らかにしたくない場合があるため、Fromヘッダーフィールドでtel URIを優先する場合があります。
This lack of authority gives rise to a whole class of SIP Identity problems when dealing with telephone numbers, as is explored in [CONCERNS]. That document shows how the Identity header of a SIP request targeting a telephone number (embedded in a SIP URI) could be dropped by an intermediate domain, which then modifies and re-signs the request, all without alerting the verification service: the verification service has no way of knowing which original domain signed the request. Provided that the local authentication service is complicit, an originator can claim virtually any telephone number, impersonating any chosen Caller ID from the perspective of the verifier. Both of these attacks are rooted in the inability of the verification service to ascertain a specific certificate that is authoritative for a telephone number.
この[権限]の欠如は、[CONCERNS]で検討されているように、電話番号を処理する際にSIP IDの問題全体を引き起こします。そのドキュメントは、電話番号（SIP URIに埋め込まれている）をターゲットとするSIP要求のIdentityヘッダーが中間ドメインによって削除され、検証サービスに警告することなく、要求を変更および再署名する方法を示しています。検証サービスリクエストに署名した元のドメインを知る方法はありません。ローカル認証サービスが複雑な場合、発信者は事実上すべての電話番号を要求し、検証者の観点から選択した発信者IDを偽装できます。これらの攻撃は両方とも、電話番号に対して信頼できる特定の証明書を確認サービスが確認できないことに起因しています。
Moreover, as deployed, SIP is highly mediated and is mediated in ways that [RFC3261] did not anticipate. As request routing commonly depends on policies dissimilar to [RFC3263], requests transit multiple intermediate domains to reach a destination; some forms of intermediaries in those domains may effectively reinitiate the session.
さらに、SIPは展開されると高度に仲介され、[RFC3261]が予期していなかった方法で仲介されます。リクエストのルーティングは一般に[RFC3263]とは異なるポリシーに依存するため、リクエストは宛先に到達するために複数の中間ドメインを通過します。これらのドメインの仲介者の一部の形式は、セッションを効果的に再開する場合があります。
One of the main reasons that SIP deployments mimic the PSTN architecture is because the requirement for interconnection with the PSTN remains paramount: a call may originate in SIP and terminate on the PSTN, or vice versa. Worse still, a PSTN-to-PSTN call may transit a SIP network in the middle, or vice versa. This necessarily reduces SIP's feature set to the least common denominator of the telephone network and mandates support for telephone numbers as a primary calling identifier.
SIP展開がPSTNアーキテクチャを模倣する主な理由の1つは、PSTNとの相互接続の要件が依然として最も重要であるためです。コールはSIPで発信され、PSTNで終了するか、またはその逆です。さらに悪いことに、PSTNからPSTNへのコールは、SIPネットワークを途中で通過したり、その逆の場合があります。これは必然的に、SIPの機能セットを電話網の最小公分母に減らし、主要な呼び出し識別子としての電話番号のサポートを義務付けます。
Interworking with non-SIP networks makes end-to-end identity problematic. When a PSTN gateway sends a call to a SIP network, it creates the INVITE request anew, regardless of whether a previous leg of the call originated in a SIP network that later delivered the call to the PSTN. As these gateways are not necessarily operated by entities that have any relationship to the number assignee, it is unclear how they could provide an identity signature that a verifier should trust. Moreover, how could the gateway know that the calling party number it receives from the PSTN is actually authentic? And when a gateway receives a call via SIP and terminates a call to the PSTN, how can that gateway verify that a telephone number in the From header field value is authentic before it presents that number as the calling party number in the PSTN?
非SIPネットワークとのインターワーキングにより、エンドツーエンドのIDが問題になります。 PSTNゲートウェイは、通話をSIPネットワークに送信すると、以前の通話のレッグが後で通話をPSTNに配信したSIPネットワークで発信されたかどうかに関係なく、INVITE要求を新しく作成します。これらのゲートウェイは、番号割り当て対象者と関係のあるエンティティによって必ずしも操作されるわけではないため、検証者が信頼する必要のあるID署名を提供する方法は不明です。さらに、ゲートウェイは、PSTNから受信した発呼者番号が実際に本物であることをどのようにして知ることができますか？また、ゲートウェイがSIPを介して通話を受信し、PSTNへの通話を終了する場合、そのゲートウェイが発信者番号をPSTNで発信者番号として提示する前に、そのゲートウェイがFromヘッダーフィールド値の電話番号が本物であることをどのように確認できますか
Similarly, some SIP networks deploy intermediaries that act as back-to-back user agents (B2BUAs), typically in order to provide policy or interworking functions at network boundaries (hence, the nickname "Session Border Controller"). These functions range from topology hiding, to alterations necessary to interoperate successfully with particular SIP implementations, to simple network address translation from private address space. To implement these functions, these entities modify SIP INVITE requests in transit, potentially changing the From, Contact, and Call-ID header field values, as well as aspects of the SDP, including especially the IP addresses and ports associated with media. Consequently, a SIP request exiting a B2BUA does not necessarily bear much resemblance to the original request received by the B2BUA, just as an SS7 request exiting a PSTN gateway may transform all aspects of the SIP request in the VoIP leg of the call. An Identity signature provided for the original INVITE has no bearing on the post-B2BUA INVITE, and, were the B2BUA to preserve the original Identity header, any verification service would detect a violation of the integrity protection.
同様に、一部のSIPネットワークは、通常はネットワーク境界でポリシーまたはインターワーキング機能を提供するために、バックツーバックユーザーエージェント（B2BUA）として機能する仲介者を展開します（したがって、「セッションボーダーコントローラー」というニックネーム）。これらの機能は、トポロジーの隠蔽から、特定のSIP実装と正常に相互運用するために必要な変更、プライベートアドレススペースからの単純なネットワークアドレス変換にまで及びます。これらの機能を実装するために、これらのエンティティは送信中のSIP INVITE要求を変更し、From、Contact、およびCall-IDヘッダーフィールドの値だけでなく、特にメディアに関連付けられたIPアドレスやポートなどのSDPの側面も変更します。その結果、B2BUAを出るSIP要求は、PSTNゲートウェイを出るSS7要求がコールのVoIPレッグのSIP要求のすべての側面を変換するのと同じように、B2BUAが受信する元の要求と必ずしも類似していません。元のINVITEに提供されたID署名は、B2BUA後のINVITEには影響せず、B2BUAが元のIdentityヘッダーを保持していた場合、検証サービスは整合性保護の違反を検出します。
The SIP community has long been aware of these problems with [RFC4474] in practical deployments. Some have therefore proposed weakening the security constraints of [RFC4474] so that at least some deployments of B2BUAs will be compatible with integrity protection of SIP requests. However, such solutions do not address the key problems identified above: the lack of any clear authority for telephone numbers and the fact that some INVITE requests are generated by intermediaries rather than endpoints. Removing the signature over the SDP from the Identity header will not, for example, make it any clearer how a PSTN gateway should assert identity in an INVITE request.
SIPコミュニティは、実際の配備における[RFC4474]のこれらの問題を長い間認識してきました。したがって、B2BUAの少なくとも一部の展開がSIPリクエストの完全性保護と互換性を持つように、[RFC4474]のセキュリティ制約を弱めることを提案している人もいます。ただし、このようなソリューションは、上記の主要な問題に対処していません。電話番号に対する明確な権限の欠如と、一部のINVITEリクエストがエンドポイントではなく仲介者によって生成されるという事実。たとえば、IDヘッダーからSDPを介して署名を削除しても、PSTNゲートウェイがINVITE要求でIDをアサートする方法が明確になりません。
Verification Involving PSTN Reachability (VIPR) directly attacks the twin problems of identifying number assignees on the Internet and coping with intermediaries that may modify signaling. To address the first problem, VIPR relies on the PSTN itself: it discovers which endpoints on the Internet are reachable via a particular PSTN number by calling the number on the PSTN to determine whom a call to that number will reach. As VIPR-enabled Internet endpoints associated with PSTN numbers are discovered, VIPR provides a rendezvous service that allows the endpoints of a call to form an out-of-band connection over the Internet; this connection allows the endpoints to exchange information that secures future communications and permits direct, unmediated SIP connections.
PSTN到達可能性を伴う検証（VIPR）は、インターネット上で番号の割り当て先を特定し、シグナリングを変更する可能性のある仲介者に対処するという2つの問題を直接攻撃します。最初の問題に対処するために、VIPRはPSTN自体に依存します。つまり、PSTNの番号を呼び出して特定のPSTN番号を介してインターネット上のどのエンドポイントに到達できるかを検出し、その番号への通話の相手を決定します。 PSTN番号に関連付けられたVIPR対応のインターネットエンドポイントが検出されると、VIPRは、通話のエンドポイントがインターネット上で帯域外接続を形成できるようにするランデブーサービスを提供します。この接続により、エンドポイントは将来の通信を保護する情報を交換し、仲介されていない直接のSIP接続を許可します。
VIPR provides these services within a fairly narrow scope of applicability. Its seminal use case is the enterprise IP Private Branch Exchange (IPBX), a device that has both PSTN connectivity and Internet connectivity, which serves a set of local users with telephone numbers; after a PSTN call has connected successfully and then ended, the PBX searches a distributed hash table to see if any VIPR-compatible devices have advertised themselves as a route for the unfamiliar number on the Internet. If advertisements exist, the originating PBX then initiates a verification process to determine whether the entity claiming to be the assignee of the unfamiliar number in fact received the successful call: this involves verifying details such as the start and stop times of the call. If the destination verifies successfully, the originating PBX provisions a local database with a route for that telephone number to the URI provided by the proven destination. Moreover, the destination gives a token to the originator that can be inserted in future call setup messages to authenticate the source of future communications.
VIPRは、かなり狭い範囲の適用範囲でこれらのサービスを提供します。その優れた使用例は、企業のIP構内交換機（IPBX）です。これは、PSTN接続とインターネット接続の両方を備え、電話番号を使用して一連のローカルユーザーにサービスを提供するデバイスです。 PSTNコールが正常に接続してから終了した後、PBXは分散ハッシュテーブルを検索して、インターネット上で見知らぬ番号のルートとしてVIPR互換デバイスがアドバタイズしていないかどうかを確認します。アドバタイズが存在する場合、発信元のPBXは確認プロセスを開始して、見知らぬ番号の譲受人であると主張するエンティティが実際に成功したコールを受信したかどうかを判断します。これには、コールの開始時間や終了時間などの詳細の確認が含まれます。宛先が正常に検証されると、発信元のPBXは、証明済みの宛先から提供されたURIへの電話番号のルートをローカルデータベースにプロビジョニングします。さらに、宛先は発信者にトークンを提供します。トークンは、将来の通信の発信元を認証するために、将来のコールセットアップメッセージに挿入できます。
Through this mechanism, the VIPR system provides a suite of properties, ones that go well beyond merely securing the origins of communications. It also provides a routing system that dynamically discovers mappings between telephone numbers and URIs, effectively building an ad hoc ENUM database in every VIPR implementation. The tokens exchanged over the out-of-band connection established by VIPR also provide an authorization mechanism for accepting calls over the Internet, which significantly reduces the potential for spam. Because the token can act as a cookie due to the presence of this out-of-band connectivity, the VIPR token is less susceptible to cut-and-paste attacks and thus needs to cover far less of a SIP request with its signature.
このメカニズムを通じて、VIPRシステムは一連のプロパティを提供します。これらのプロパティは、単に通信の発信元を保護するだけではありません。また、電話番号とURI間のマッピングを動的に検出するルーティングシステムを提供し、すべてのVIPR実装でアドホックENUMデータベースを効果的に構築します。 VIPRによって確立されたアウトオブバンド接続を介して交換されるトークンは、インターネット経由の呼び出しを受け入れるための承認メカニズムも提供し、スパムの可能性を大幅に削減します。このアウトオブバンド接続の存在により、トークンはCookieとして機能できるため、VIPRトークンはカットアンドペースト攻撃の影響を受けにくく、シグネチャでカバーする必要のあるSIPリクエストがはるかに少なくなります。
Due to its narrow scope of applicability and the details of its implementation, VIPR has some significant limitations. The most salient for the purposes of this document is that it only has bearing on repeated communications between entities: it has no solution to the classic "robocall" problem, where the target typically receives a call from a number that has never called before. All of VIPR's strengths in establishing identity and spam prevention kick in only after an initial PSTN call has been completed and subsequent attempts at communication begin. Every VIPR-compliant entity, moreover, maintains its own stateful database of previous contacts and authorizations, which lends itself more to aggregators like IP PBXs that may front for thousands of users than to individual phones. That database must be refreshed by periodic PSTN calls to determine that control over the number has not shifted to some other entity; figuring out when data has grown stale is one of the challenges of the architecture. As VIPR requires compliant implementations to operate both a PSTN interface and an IP interface, it has little apparent applicability to ordinary desktop PCs or similar devices with no ability to place direct PSTN calls.
適用範囲が狭いこととその実装の詳細により、VIPRにはいくつかの重要な制限があります。このドキュメントの目的で最も目立つのは、エンティティ間の繰り返し通信にのみ影響することです。これは、通常、ターゲットが以前に呼び出したことのない番号から呼び出しを受信するという従来の「robocall」問題に対する解決策はありません。アイデンティティとスパム防止の確立におけるVIPRの長所はすべて、最初のPSTNコールが完了し、その後の通信の試行が開始された後にのみ開始されます。さらに、すべてのVIPR準拠のエンティティは、以前の連絡先と承認の独自のステートフルデータベースを維持します。これにより、個々の電話よりも数千人のユーザーに対応できるIP PBXなどのアグリゲーターに役立ちます。このデータベースは、定期的なPSTNコールによって更新して、番号の制御が他のエンティティに移行していないことを確認する必要があります。データが古くなっている時期を把握することは、アーキテクチャの課題の1つです。 VIPRは、PSTNインターフェイスとIPインターフェイスの両方を動作させるための準拠した実装を必要とするため、直接PSTNコールを発信する機能がない通常のデスクトップPCまたは同様のデバイスにはほとんど適用できません。
The distributed hash table (DHT) also creates a new attack surface for impersonation. Attackers who want to pose as the owners of telephone numbers can advertise themselves as routes to a number in the hash table. VIPR has no inherent restriction on the number of entities that may advertise themselves as routes for a number; thus, an originator may find multiple advertisements for a number on the DHT even when an attack is not in progress. Attackers may learn from these validation attempts which VIPR entities recently placed calls to the target number, even if they cannot impersonate the target since they lack the PSTN call detail information. It may be that this information is all the attacker hopes to glean. The fact that advertisements and verifications are public results from the public nature of the DHT that VIPR creates. The public DHT prevents any centralized control or attempts to impede communications, but those come at the cost of apparently unavoidable privacy losses.
分散ハッシュテーブル（DHT）は、偽装のための新しい攻撃面も作成します。電話番号の所有者になりすます攻撃者は、ハッシュテーブル内の番号へのルートとしてアドバタイズできます。 VIPRは、番号のルートとして自分自身をアドバタイズできるエンティティの数に固有の制限はありません。したがって、発信者は、攻撃が進行中でない場合でも、DHT上の番号に対する複数のアドバタイズを見つける可能性があります。攻撃者は、これらの検証の試みから、PSTNコールの詳細情報がないためにターゲットを偽装できない場合でも、VIPRエンティティが最近ターゲット番号にコールを発信したことを知ることがあります。この情報は、攻撃者が収集したいすべての情報である可能性があります。広告と検証がパブリックであるという事実は、VIPRが作成するDHTのパブリックな性質によるものです。パブリックDHTは、集中管理や通信を妨害しようとする試みを防ぎますが、それらは明らかに避けられないプライバシーの損失を犠牲にしています。
Because of these limitations, VIPR, much like SIP Identity, has had little impact in the marketplace. Ultimately, VIPR's utility as an identity mechanism is limited by its reliance on the PSTN, especially its need for an initial PSTN call to complete before any of VIPR's benefits can be realized, and by the drawbacks of the highly public exchanges required to create the out-of-band connection between VIPR entities. As such, there is no obvious solution to providing secure origin services for SIP on the Internet today.
これらの制限のため、VIPRはSIP Identityと同様に、市場にほとんど影響を与えていません。結局のところ、アイデンティティメカニズムとしてのVIPRのユーティリティは、PSTNへの依存、特にVIPRのメリットを実現する前に最初のPSTNコールを完了する必要があること、およびアウトバウンドを作成するために必要な高度なパブリックエクスチェンジの欠点によって制限されます。 VIPRエンティティ間の帯域外接続。そのため、今日のインターネット上のSIPに安全なオリジンサービスを提供する明確なソリューションはありません。
In the years since [RFC4474] was conceived, there have been a number of fundamental shifts in the communications marketplace. The most transformative has been the precipitous rise of mobile smartphones, which are now arguably the dominant communications device in the developed world. Smart phones have both a PSTN and an IP interface, as well as SMS and Multimedia Messaging Service (MMS) capabilities. This suite of tools suggests that some of the techniques proposed by VIPR could be adapted to the smartphone environment. The installed base of smartphones is, moreover, highly upgradable and permits rapid adoption of out-of-band rendezvous services for smartphones that bypass the PSTN. Mobile messaging services that use telephone numbers as identities allow smartphone users to send text messages to one another over the Internet rather than over the PSTN. Like VIPR, such services create an out-of-band connection over the Internet between smartphones; unlike VIPR, the rendezvous service is provided by a trusted centralized database rather than by a DHT, and it is the centralized database that effectively verifies and asserts the telephone number of the sender of a message. While such messaging services are specific to the users of the specific service, it seems clear that similar databases could be provided by neutral third parties in a position to coordinate between endpoints.
[RFC4474]が考案されてからの数年間、通信市場には多くの根本的な変化がありました。最も変革を遂げたのは、モバイルスマートフォンの急激な台頭であり、現在では間違いなく先進国の主要な通信デバイスとなっています。スマートフォンには、PSTNとIPの両方のインターフェイス、およびSMSとマルチメディアメッセージングサービス（MMS）の機能があります。この一連のツールは、VIPRによって提案された手法の一部をスマートフォン環境に適合させることができることを示唆しています。さらに、スマートフォンのインストールベースは高度にアップグレード可能であり、PSTNをバイパスするスマートフォンに帯域外ランデブーサービスを迅速に採用できます。電話番号をIDとして使用するモバイルメッセージングサービスを使用すると、スマートフォンユーザーは、PSTNではなくインターネットを介して相互にテキストメッセージを送信できます。 VIPRと同様に、このようなサービスはスマートフォン間でインターネットを介して帯域外接続を作成します。 VIPRとは異なり、ランデブーサービスは、DHTではなく、信頼された集中型データベースによって提供されます。メッセージの送信者の電話番号を効果的に確認およびアサートするのは、集中型データベースです。このようなメッセージングサービスは特定のサービスのユーザーに固有のものですが、エンドポイント間で調整する立場にある中立のサードパーティが同様のデータベースを提供できることは明らかです。
At the time [RFC4474] was written, the hopes for establishing a certificate authority for telephone numbers on the Internet largely rested on public ENUM deployment. The e164.arpa DNS tree established for ENUM could have grown to include certificates for telephone numbers or at least for number ranges. It is now clear, however, that public ENUM as originally envisioned has little prospect for adoption. That said, some national authorities for telephone numbers are migrating their provisioning services to the Internet and issuing credentials that express authority for telephone numbers to secure those services. These new authorities for numbers could provide to the public Internet the necessary signatory authority for securing calling party numbers. While these systems are far from universal, the authors of this document believe that a solution devised for the North American Numbering Plan could have applicability to other country codes.
[RFC4474]が書かれた時点で、インターネット上に電話番号の認証局を設立することへの期待は、主にパブリックENUMの展開に依存していました。 ENUM用に確立されたe164.arpa DNSツリーは、電話番号または少なくとも番号範囲の証明書を含むように成長する可能性があります。ただし、当初想定されていたパブリックENUMが採用される見込みはほとんどないことが、現在では明らかです。とはいえ、電話番号の一部の国内当局は、プロビジョニングサービスをインターネットに移行し、それらのサービスを保護するために電話番号の権限を明示する資格情報を発行しています。これらの新しい番号権限は、発呼者番号を保護するために必要な署名権限を公衆インターネットに提供する可能性があります。これらのシステムは普遍的ではありませんが、このドキュメントの作成者は、北米の番号計画のために考案されたソリューションが他の国のコードにも適用できると考えています。
There have been a number of recent high-profile compromises of web certificate authorities. The presence of numerous (in some cases, hundreds) trusted certificate authorities in modern web browsers has become a significant security liability. As [RFC4474] relied on web certificate authorities, this too provides new lessons for any work on revising [RFC4474], namely, that innovations like DNS-Based Authentication of Named Entities (DANE) [RFC6698], which designate a specific certificate preferred by the owner of a DNS name, could greatly improve the security of a SIP Identity mechanism and, moreover, that when considering new certificate authorities for telephone numbers, we should be wary of excessive pluralism. While a chain of delegation with a progressively narrowing scope of authority (e.g., from a regulatory entity, to a carrier, to a reseller, to an end user) is needed to reflect operational practices, there is no need to have multiple roots or peer entities that both claim authority for the same telephone number or number range.
最近、Web認証局の多くの注目を集める侵害がありました。最新のWebブラウザーに多数（場合によっては数百）の信頼できる認証局が存在することは、重大なセキュリティ上の責任となっています。 [RFC4474]はWeb認証局に依存していたので、これも[RFC4474]の改訂に関する作業、つまりDNSによる名前付きエンティティの認証（DANE）[RFC6698]のような、特定の証明書をDNS名の所有者は、SIP IDメカニズムのセキュリティを大幅に向上させることができ、さらに、電話番号の新しい認証局を検討する場合、過度の多元性に注意する必要があります。運用慣行を反映するために、権限の範囲が徐々に狭くなる委任のチェーン（たとえば、規制エンティティからキャリア、リセラー、エンドユーザーまで）が必要ですが、複数のルーツやピアを持つ必要はありません両方が同じ電話番号または番号範囲の権限を主張するエンティティ。
Given the prevalence of established B2BUA deployments, we may have a further opportunity to review the elements signed using the SIP Identity mechanism [RFC4474] and to decide on the value of alternative signature mechanisms. Separating the elements necessary for (a) securing the From header field value and preventing replays from (b) the elements necessary to prevent men-in-the-middle from tampering with messages may also yield a strategy for identity that will be practicable in some highly mediated networks. Solutions in this space must, however, remain mindful of the requirements for securing cryptographic material necessary to support Datagram Transport Layer Security for Secure RTP (DTLS-SRTP) or future security mechanisms.
確立されたB2BUA展開が普及していることを考えると、SIP IDメカニズム[RFC4474]を使用して署名された要素を確認し、代替の署名メカニズムの値を決定する機会がさらにあるかもしれません。 （a）Fromヘッダーフィールドの値を確保し、リプレイを防止するために必要な要素を分離する（b）中間者がメッセージを改ざんするのを防ぐために必要な要素も、一部で実行可能なIDの戦略をもたらす可能性がある高度に仲介されたネットワーク。ただし、この分野のソリューションは、Secure RTP（DTLS-SRTP）のデータグラムトランスポート層セキュリティまたは将来のセキュリティメカニズムをサポートするために必要な暗号素材を保護するための要件に注意を払う必要があります。
One thing that has not changed, and is not likely to change in the future, is the transitive nature of trust in the PSTN. When a call from the PSTN arrives at a SIP gateway with a calling party number, the gateway will have little chance of determining whether the originator of the call was authorized to claim that calling party number. Due to roaming and countless other factors, calls on the PSTN may emerge from administrative domains that were not assigned the originating number. This use case will remain the most difficult to tackle for an identity system and may prove beyond repair. It does, however, seem that with the changes in the solution space, and a better understanding of the limits of [RFC4474] and VIPR, we are today in a position to reexamine the problem space and find solutions that can have a significant impact on the secure origins problem.
変更されておらず、将来変更される可能性が低いことの1つは、PSTNにおける信頼の推移的な性質です。 PSTNからのコールが発呼者番号のあるSIPゲートウェイに到着した場合、ゲートウェイは、コールの発信者がその発呼者番号を要求することを許可されているかどうかを判断する機会がほとんどありません。ローミングやその他の無数の要因により、PSTN上のコールは、発信番号が割り当てられていない管理ドメインから発信される場合があります。このユースケースは、アイデンティティシステムに取り組むのが最も難しいままであり、修復を超えて証明される可能性があります。しかし、ソリューションスペースの変更、および[RFC4474]とVIPRの制限の理解により、今日、問題のスペースを再検討し、次の点に大きな影響を与える可能性のあるソリューションを見つけることができるようです。安全な起源の問題。
While spoofing the origins of communication is a source of numerous security concerns, solutions for identifying communications must also be mindful of the security risks of pervasive monitoring (see [RFC7258]). Identifying information, once it is attached to communications, can potentially be inspected by parties other than the intended recipient and collected for any number of reasons. As stated above, the purpose of this work is not to eliminate anonymity; furthermore, to be viable and in the public interest, solutions should not facilitate the unauthorized collection of calling data.
通信の発信元を偽装することは、多くのセキュリティ問題の原因ですが、通信を特定するためのソリューションは、広範囲にわたる監視のセキュリティリスクにも注意する必要があります（[RFC7258]を参照）。識別情報は、通信に添付されると、意図した受信者以外の関係者によって検査され、さまざまな理由で収集される可能性があります。上記のように、この作業の目的は匿名性を排除することではありません。さらに、実行可能で公共の利益のために、ソリューションは呼び出しデータの不正な収集を容易にすべきではありません。
Currently, telephone numbers are typically managed in a loose delegation hierarchy. For example, a national regulatory agency may task a private, neutral entity with administering numbering resources, such as area codes, and a similar entity with assigning number blocks to carriers and other authorized entities, who in turn then assign numbers to customers. Resellers with looser regulatory obligations can complicate the picture, and in many cases, it is difficult to distinguish the roles of enterprises from carriers. In many countries, individual numbers are portable between carriers, at least within the same technology (e.g., wireline-to-wireline). Separate databases manage the mapping of numbers to switch identifiers, companies, and textual Caller ID information.
現在、電話番号は通常、緩やかな委任階層で管理されています。たとえば、国の規制機関は、市外局番などの番号付けリソースの管理を民間の中立エンティティに任命し、同様に、キャリアに番号ブロックを割り当て、他の許可されたエンティティは顧客に番号を割り当てます。規制義務が緩いリセラーは状況を複雑にする可能性があり、多くの場合、企業とキャリアの役割を区別することは困難です。多くの国では、個々の番号は、少なくとも同じテクノロジー（例：有線間）内では、キャリア間で移植可能です。個別のデータベースが番号のマッピングを管理し、識別子、会社、およびテキストの発信者ID情報を切り替えます。
As the PSTN transitions to using VoIP technologies, new assignment policies and management mechanisms are likely to emerge. For example, it has been proposed that geography could play a smaller role in number assignments, that individual numbers could be assigned to end users directly rather than only to service providers, and that the assignment of numbers does not have to depend on providing actual call delivery services.
PSTNがVoIPテクノロジの使用に移行すると、新しい割り当てポリシーと管理メカニズムが出現する可能性があります。たとえば、地理が番号の割り当てにおいてより小さな役割を果たす可能性があること、個々の番号がサービスプロバイダーだけでなくエンドユーザーに直接割り当てられる可能性があること、および番号の割り当てが実際の通話の提供に依存する必要がないことが提案されています配達サービス。
Databases today already map telephone numbers to entities that have been assigned the number, e.g., through the LERG (Local Exchange Routing Guide) in the United States. Thus, the transition to IP-based networks may offer an opportunity to integrate cryptographic bindings between numbers or number ranges and service providers into databases.
今日のデータベースはすでに、電話番号を、たとえば米国のLERG（Local Exchange Routing Guide）を通じて番号が割り当てられているエンティティにマッピングしています。したがって、IPベースのネットワークへの移行は、数値または数値範囲とサービスプロバイダー間の暗号バインディングをデータベースに統合する機会を提供する可能性があります。
This section describes only the high-level requirements of the STIR effort, which we expect will be further articulated as work continues:
このセクションでは、STIR作業の高レベルの要件についてのみ説明します。これは、作業が継続するにつれてさらに明確になると予想されます。
Generation: Intermediaries as well as end systems must be able to generate the source identity information.
生成：中間システムとエンドシステムは、ソースID情報を生成できる必要があります。
Validation: Intermediaries as well as end systems must be able to validate the source identity information.
検証：仲介者とエンドシステムは、ソースID情報を検証できる必要があります。
Usability: Any validation mechanism must work without human intervention, for example, without mechanisms like CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart).
使いやすさ：CAPTCHA（コンピューターと人間を区別するための完全に自動化されたパブリックチューリングテスト）などのメカニズムがなくても、検証メカニズムは人間の介入なしで機能する必要があります。
Deployability: Must survive transition of the call to the PSTN and the presence of B2BUAs.
展開可能性：PSTNへの通話の移行およびB2BUAの存在に耐えなければなりません。
Reflecting existing authority: Must stage credentials on existing national-level number delegations, without assuming the need for an international golden root on the Internet.
既存の権限を反映する：インターネット上の国際的なゴールデンルートの必要性を想定せずに、既存の全国レベルの数の代表団に資格情報をステージングする必要があります。
Accommodating current practices: Must allow number portability among carriers and must support legitimate usage of number spoofing (e.g., doctors' offices and call centers).
現在の慣行に対応する：キャリア間での番号のポータビリティを可能にし、番号のなりすましの正当な使用をサポートする必要があります（例：医師のオフィスやコールセンター）。
Minimal payload overhead: Must lead to minimal expansion of SIP header fields to avoid fragmentation in deployments that use UDP.
最小限のペイロードオーバーヘッド：UDPを使用する展開での断片化を回避するために、SIPヘッダーフィールドの最小限の拡張につながる必要があります。
Efficiency: Must minimize RTTs for any network lookups and minimize any necessary cryptographic operations.
効率：ネットワーク検索のRTTを最小限に抑え、必要な暗号化操作を最小限に抑える必要があります。
Privacy: A solution must minimize the amount of information that an unauthorized party can learn about what numbers have been called by a specific caller and what numbers have called a specific called party.
プライバシー：ソリューションは、未承認の当事者が特定の発信者が呼び出した番号と特定の着信者を呼び出した番号について知ることができる情報の量を最小限に抑える必要があります。
Some requirements specifically outside the scope of the effort include:
特に取り組みの範囲外の要件には、次のものがあります。
Display name: This effort does not consider how the display name of the caller might be validated.
表示名：この作業では、呼び出し元の表示名を検証する方法は考慮されません。
Response authentication: This effort only considers the problem of providing secure telephone identity for requests, not for responses to requests; no solution is proposed for the problem of determining to which number a call has connected [RFC4916].
応答認証：この取り組みでは、要求に対する応答ではなく、要求に対して安全な電話IDを提供するという問題のみを考慮しています。コールが接続している番号を特定する問題の解決策は提案されていません[RFC4916]。
We would like to thank Sanjay Mishra, Fernando Mousinho, David Frankel, Penn Pfautz, Mike Hammer, Dan York, Andrew Allen, Philippe Fouquart, Hadriel Kaplan, Richard Shockey, Russ Housley, Alissa Cooper, Bernard Aboba, Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for the discussion and input that contributed to this document.
Sanjay Mishra、Fernando Mousinho、David Frankel、Penn Pfautz、Mike Hammer、Dan York、Andrew Allen、Philippe Fouquart、Hadriel Kaplan、Richard Shockey、Russ Housley、Alissa Cooper、Bernard Aboba、Sean Turner、Brian Rosen、このドキュメントに貢献したディスカッションと意見を提供してくれたEric BurgerとEric Rescorla。
This document is about improving the security of call origin identification; security considerations for specific solutions will be discussed in solutions documents.
このドキュメントは、発信元識別のセキュリティを向上させることを目的としています。特定のソリューションのセキュリティに関する考慮事項については、ソリューションドキュメントで説明します。
[CONCERNS] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, February 2008.
[懸念] Rosenberg、J。、「RFC 4474の適用性に関する懸念」、Work in Progress、2008年2月。
[NEWS-HACK] Wikipedia, "News International phone hacking scandal", June 2014, <http://en.wikipedia.org/w/index.php?title=News _International_phone_hacking_scandal&oldid=614607591>.
[ニュースハック]ウィキペディア、「ニュースインターナショナルの電話ハッキングスキャンダル」、2014年6月、<http://en.wikipedia.org/w/index.php?title=News _International_phone_hacking_scandal＆oldid = 614607591>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324] Watson、M.、「ネットワークアサートされたIDの短期要件」、RFC 3324、2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「Trusted Networks内のAsserted IdentityのためのSession Initiation Protocol（SIP）のプライベート拡張」、RFC 3325、2002年11月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、2004年12月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916] Elwell、J。、「Connected Identity in the Session Initiation Protocol（SIP）」、RFC 4916、2007年6月。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5039] Rosenberg、J。およびC. Jennings、「The Session Initiation Protocol（SIP）and Spam」、RFC 5039、2008年1月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、2010年3月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティの認証（DANE）トランスポート層セキュリティ（TLS）プロトコル：TLSA」、RFC 6698、2012年8月。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is Is a Attack」、BCP 188、RFC 7258、2014年5月。
[ROBOCALL-CHALLENGE] Federal Trade Commission (FTC), "FTC Robocall Challenge", <http://robocall.challenge.gov/>.
[ROBOCALL-CHALLENGE]連邦取引委員会（FTC）、「FTC Robocall Challenge」、<http://robocall.challenge.gov/>。
[ROBOCALL-FCC] Federal Communications Commission (FCC), "Robocalls", April 2013, <http://www.fcc.gov/guides/robocalls>.
[ROBOCALL-FCC]連邦通信委員会（FCC）、「Robocalls」、2013年4月、<http://www.fcc.gov/guides/robocalls>。
[SECURE-ORIGIN] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, "Secure Call Origin Identification", Work in Progress, November 2012.
[SECURE-ORIGIN] Cooper、A.、Tschofenig、H.、Peterson、J。、およびB. Aboba、「Secure Call Origin Identification」、Work in Progress、2012年11月。
[SIP-SECURITY] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, February 2005.
[SIP-SECURITY] Peterson、J。、「SIPのリターゲティングとセキュリティ：フレームワークと要件」、進行中の作業、2005年2月。
[SWATTING] The Federal Bureau of Investigation (FBI), "Don't Make the Call: The New Phenomenon of 'Swatting'", February 2008, <http://www.fbi.gov/news/stories/2008/february/ swatting020408>.
[SWATTING]連邦捜査局（FBI）、「Do n't Make the Call：The New Phenomenon of 'Swatting'」、2008年2月、<http://www.fbi.gov/news/stories/2008/february / swatting020408>。
[TDOS] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on Public Emergency Networks", April 2013, <http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-attacks-on-public-emergency-networks/>.
[TDOS]クレブス、B。、「DHSが公衆緊急ネットワークへの「TDoS」恐喝攻撃を警告する」、2013年4月、<http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-attacks -on-public-emergency-networks />。
[VIPR-OVERVIEW] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-Huguenin, "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Work in Progress, December 2013.
[VIPRの概要] Barnes、M.、Jennings、C.、Rosenberg、J。、およびM. Petit-Huguenin、「PSTNの到達可能性に関する検証：要件とアーキテクチャの概要」、2013年12月、作業中。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Jon Peterson NeuStar、Inc. 1800 Sutter St Suite 570 Concord、CA 94520 US
EMail: jon.peterson@neustar.biz
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig Hall, Tirol 6060 Austria
Hannes Tschofenig Hall、チロル6060オーストリア
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at