[要約] RFC 7375は、セキュアな電話番号の身元情報の脅威モデルに関するものであり、その目的は、電話番号の身元情報のセキュリティ上の脅威を明確にし、対策を提案することです。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 7375 NeuStar, Inc.
Category: Informational October 2014
ISSN: 2070-1721
Secure Telephone Identity Threat Model
安全な電話アイデンティティ脅威モデル
Abstract
概要
As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can 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. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.
インターネットと電話ネットワークの相互接続と相互依存がますます高まっているため、攻撃者は、大量の商用通話スキームを調整したり、ボイスメールボックスをハッキングしたり、銀行が信頼する多要素認証システムを迂回したりするときに、発信者番号を偽装または不明瞭にすることができます。このドキュメントでは、結果として生じるシステムの脅威を分析し、アクターを列挙し、攻撃者が利用できる機能を確認し、攻撃が開始されるシナリオについて説明します。
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/rfc7375.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7375で入手できます。
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 and Scope ..........................................2
2. Actors ..........................................................4
2.1. Endpoints ..................................................4
2.2. Intermediaries .............................................5
2.3. Attackers ..................................................6
3. Attacks .........................................................6
3.1. Voicemail Hacking via Impersonation ........................7
3.2. Unsolicited Commercial Calling from Impersonated Numbers ...8
3.3. Telephony Denial-of-Service Attacks ........................9
4. Attack Scenarios ...............................................10
4.1. Solution-Specific Attacks .................................11
5. Security Considerations ........................................11
6. Informative References .........................................12
Acknowledgments ...................................................12
Author's Address ..................................................13
As is discussed in the STIR problem statement [RFC7340] (where "STIR" refers to the Secure Telephone Identity Revisited working group), the primary enabler of robocalling, vishing, swatting, and related attacks is the capability to impersonate a calling party number. The starkest examples of these attacks are cases where automated callees on the Public Switched Telephone Network (PSTN) rely on the calling number as a security measure, for example, to access a voicemail system. Robocallers use impersonation as a means of obscuring identity. While robocallers can, in the ordinary PSTN, block (that is, withhold) their calling number from presentation, callees are less likely to pick up calls from blocked identities; therefore, appearing to call from some number, any number, is preferable.
STIR問題ステートメント[RFC7340]（「STIR」はSecure Telephone Identity Revisitedワーキンググループを指します）で説明されているように、ロボコール、ビッシング、スワッティング、および関連する攻撃の主要なイネーブラーは、発呼者番号を偽装する機能です。これらの攻撃の最も明白な例は、公衆交換電話網（PSTN）の自動呼び出し先が、ボイスメールシステムへのアクセスなどのセキュリティ対策として発番号に依存している場合です。ロボコーラーは、身元を隠す手段として偽装を使用します。ロボ発信者は通常のPSTNで発信者番号をプレゼンテーションからブロック（つまり、差し控える）できますが、着信者はブロックされたIDからのコールをピックアップする可能性が低くなります。したがって、ある番号、任意の番号から電話をかけているように見えることが好ましいです。
However, robocallers prefer not to call from a number that can trace back to the them, so they impersonate numbers that are not assigned to them.
ただし、ロボ発信者は、自分にさかのぼることができる番号から電話をかけたくないので、自分に割り当てられていない番号を偽装します。
The scope of impersonation in this threat model pertains solely to the rendering of a calling telephone number to a callee (human user or automaton) at the time of call setup. The primary attack vector is therefore one where the attacker contrives for the calling telephone number in signaling to be a chosen number. In this attack, the number is one that the attacker is not authorized to use (as a caller) but gives in order for that number to be consumed or rendered on the terminating side. The threat model assumes that this attack simply cannot be prevented: there is no way to stop the attacker from creating call setup messages that contain attacker-chosen calling telephone numbers. The solution space therefore focuses on ways that terminating or intermediary elements might differentiate authorized from unauthorized calling party numbers in order that policies, human or automatic, might act on that information.
この脅威モデルのなりすましの範囲は、呼び出しのセットアップ時に呼び出し先の電話番号を呼び出し先（人間のユーザーまたはオートマトン）に提供することのみに関係します。したがって、主要な攻撃ベクトルは、攻撃者がシグナリングの発信電話番号を選択した番号になるように工夫するものです。この攻撃では、番号は攻撃者が（発信者として）使用することを許可されていないが、その番号が終端側で消費またはレンダリングされるために与える番号です。脅威モデルは、この攻撃を防止できないことを前提としています。攻撃者が選択した発信者の電話番号を含む通話設定メッセージを攻撃者が作成するのを阻止する方法はありません。したがって、ソリューションスペースでは、人間または自動のポリシーがその情報に作用するために、終端要素または中間要素が許可された発呼者番号と許可されていない発呼者番号を区別する方法に焦点を当てています。
Securing an authenticated calling party number at call setup time does not entail any assertions about the entity or entities that will send and receive media during the call itself. In call paths with intermediaries and gateways (as described below), there may be no way to provide any assurance in the signaling about participants in the media of a call. In those end-to-end IP environments where such assurance is possible, it is highly desirable. However, in the threat model described in this document, "impersonation" does not consider impersonating an authorized listener after a call has been established (e.g., as a third party attempting to eavesdrop on a conversation). Attackers that could impersonate an authorized listener require capabilities that robocallers and voicemail hackers are unlikely to possess, and historically, such attacks have not played a role in enabling robocalling or related problems.
コールのセットアップ時に認証された発番号を保護しても、コール自体の間にメディアを送受信するエンティティに関するアサーションは必要ありません。仲介者とゲートウェイを備えたコールパス（以下で説明）では、コールのメディアの参加者に関するシグナリングを保証する方法がない場合があります。このような保証が可能なエンドツーエンドのIP環境では、非常に望ましいです。ただし、このドキュメントで説明されている脅威モデルでは、「なりすまし」は、通話が確立された後（たとえば、第三者が会話を盗聴しようとして）に、許可されたリスナーを偽装することを考慮していません。許可されたリスナーになりすます可能性のある攻撃者には、ロボコールャーやボイスメールハッカーが持つ可能性が低い機能が必要です。これまで、このような攻撃は、ロボコールや関連する問題を可能にする役割を果たしていません。
In SIP, and even many traditional telephone protocols, call signaling can be renegotiated after the call has been established. Using various transfer mechanisms common in telephone systems, a callee can easily be connected to, or conferenced in with, telephone numbers other than the original calling number once a call has been established. These post-setup changes to the call are outside the scope of impersonation considered in this model: the motivating use cases of defeating robocalling, voicemail hacking, and swatting all rely on impersonation during the initial call setup. Furthermore, this threat model does not include in its scope the verification of the reached party's telephone number back to the originator of the call. There is no assurance to the originator that they are reaching the correct number, nor any indication when call forwarding has taken place. This threat model is focused only on verifying the calling party number to the callee.
SIP、および多くの従来の電話プロトコルでも、コールが確立された後、コールシグナリングを再ネゴシエートできます。電話システムで一般的なさまざまな転送メカニズムを使用して、通話が確立されると、着信者は元の発信者番号以外の電話番号に簡単に接続したり、電話会議に参加したりできます。通話に対するこれらのセットアップ後の変更は、このモデルで考慮される偽装の範囲外です。ロボコール、ボイスメールハッキング、およびスワッティングを無効にする動機付けのユースケースはすべて、初期の通話セットアップ中の偽装に依存しています。さらに、この脅威モデルは、その範囲に、通話の発信者に到達した相手の電話番号の検証を含みません。発信者が正しい番号に到達しているという保証も、コール転送が行われたことを示すものもありません。この脅威モデルは、呼び出し先への呼び出し元番号の確認のみに焦点を当てています。
In much of the PSTN, there exists a supplemental service that translates calling party numbers into names, including the proper names of people and businesses, for rendering to the called user. These services (frequently marketed as part of 'Caller ID') provide a further attack surface for impersonation. The threat model described in this document addresses only the calling party number, even though presenting a forged calling party number may cause a chosen calling party name to be rendered to the user as well. Providing a verifiable calling party number therefore improves the security of calling party name systems, but this threat model does not consider attacks specific to names. Such attacks may be carried out against the databases consulted by the terminating side of a call to provide calling party names or by impersonators forging a particular calling party number in order to present a misleading name to the user.
PSTNの多くには、呼び出し元の番号を、呼び出し先のユーザーに表示するために、人や会社の適切な名前を含む名前に変換する補足サービスが存在します。これらのサービス（「発信者ID」の一部として頻繁に販売される）は、なりすましに対するさらなる攻撃面を提供します。このドキュメントで説明する脅威モデルは、発信者番号のみを対象としていますが、偽造された発信者番号を提示すると、選択された発信者名もユーザーに表示される場合があります。したがって、検証可能な発呼側番号を提供すると、発呼側のネームシステムのセキュリティが向上しますが、この脅威モデルでは、名前に固有の攻撃は考慮されません。そのような攻撃は、発呼者名を提供するために呼の終端側によって参照されるデータベースに対して、またはユーザーに誤解を招く名前を提示するために特定の発呼者番号を偽造することによって実行される可能性があります。
There are two main categories of end-user terminals relevant to this discussion, a dumb device (such as a 'black phone') or a smart device:
この議論に関連するエンドユーザー端末には、主に2つのカテゴリ、ダムデバイス（「ブラックフォン」など）またはスマートデバイスがあります。
o Dumb devices comprise a simple dial pad, handset, and ringer, optionally accompanied by a display that can render a limited number of characters. Typically, the display renders enough characters for a telephone number and an accompanying name, but sometimes fewer are rendered. Although users interface with these devices, the intelligence that drives them lives in the service provider network.
o ダムデバイスは、シンプルなダイヤルパッド、ハンドセット、および呼び出し音で構成され、オプションで限られた数の文字を表示できるディスプレイが付属しています。通常、ディスプレイには電話番号と付随する名前に十分な文字数が表示されますが、表示される文字数が少ない場合もあります。ユーザーはこれらのデバイスとインターフェイスしますが、それらを駆動するインテリジェンスはサービスプロバイダーネットワークにあります。
o Smart devices are general-purpose computers with some degree of programmability and with the capacity to access the Internet and to render text, audio, and/or images. This category includes smart phones, telephone applications on desktop and laptop computers, IP private branch exchanges, etc.
o スマートデバイスは、ある程度のプログラマビリティを備え、インターネットにアクセスし、テキスト、オーディオ、画像をレンダリングする機能を備えた汎用コンピュータです。このカテゴリには、スマートフォン、デスクトップおよびラップトップコンピュータ上の電話アプリケーション、IP構内交換機などが含まれます。
There is a further category of automated terminals without an end user. These include systems like voicemail services, which may provide a different set of services to a caller based solely on the calling party's number, for example, granting the (purported) mailbox owner access to a menu while giving other callers only the ability to leave a message. Though the capability of voicemail services varies widely, many today have Internet access and advanced application interfaces (to render 'visual voicemail' [OMTP-VV], to automatically transcribe voicemail to email, etc.).
エンドユーザーのいない自動端末には、さらに別のカテゴリがあります。これには、ボイスメールサービスなどのシステムが含まれます。このシステムでは、発信者の番号のみに基づいて発信者に異なるサービスのセットを提供できます。たとえば、メールボックスの所有者にメニューへのアクセスを許可し、他の発信者にはメッセージ。ボイスメールサービスの機能はさまざまですが、今日の多くはインターネットアクセスと高度なアプリケーションインターフェイスを備えています（「ビジュアルボイスメール」[OMTP-VV]のレンダリング、ボイスメールの電子メールへの自動転記など）。
The endpoints of a traditional telephone call connect through numerous intermediary devices in the network. The set of intermediary devices traversed during call setup between two endpoints is referred to as a call path. The length of the call path can vary considerably: it is possible in Voice over IP (VoIP) deployments for two endpoint entities to send traffic to one another directly, but, more commonly, several intermediaries exist in a VoIP call path. One or more gateways also may appear on a call path.
従来の通話のエンドポイントは、ネットワーク内の多数の中間デバイスを介して接続します。 2つのエンドポイント間の通話のセットアップ中に通過する中間デバイスのセットは、通話パスと呼ばれます。コールパスの長さはかなり変動する可能性があります。Voiceover IP（VoIP）の展開では、2つのエンドポイントエンティティが互いにトラフィックを直接送信することが可能ですが、VoIPコールパスには複数の仲介者が存在します。 1つ以上のゲートウェイが呼び出しパスに表示される場合もあります。
o Intermediaries forward call signaling to the next device in the path. These intermediaries may also modify the signaling in order to improve interoperability, to enable proper network-layer media connections, or to enforce operator policy. This threat model assumes there are no restrictions on the modifications to signaling that an intermediary can introduce (which is consistent with the observed behavior of such devices).
o 仲介者は、コールシグナリングをパス内の次のデバイスに転送します。これらの仲介者は、相互運用性を向上させるため、適切なネットワーク層メディア接続を可能にするため、またはオペレーターポリシーを適用するために、シグナリングを変更することもあります。この脅威モデルは、仲介者が導入できるシグナリングへの変更に制限がないことを前提としています（これは、このようなデバイスで観測された動作と一致しています）。
o A gateway is a subtype of intermediary that translates call signaling from one protocol into another. In the process, they tend to consume any signaling specific to the original protocol (elements like transaction-matching identifiers) and may need to transcode or otherwise alter identifiers as they are rendered in the destination protocol.
o ゲートウェイは、コールシグナリングを1つのプロトコルから別のプロトコルに変換する中間体のサブタイプです。このプロセスでは、元のプロトコルに固有のシグナリング（トランザクション一致識別子などの要素）を消費する傾向があり、宛先プロトコルでレンダリングされるときに識別子をトランスコードするか、または変更する必要がある場合があります。
This threat model assumes that intermediaries and gateways can forward and retarget calls as necessary, which can result in a call terminating at a place the originator did not expect; this is a common condition in call routing. This observation is significant to the solution space because it limits the ability of the originator to anticipate what the telephone number of the respondent will be (for more on the "unanticipated respondent" problem, see [SIP-SECURITY]).
この脅威モデルでは、仲介者とゲートウェイが必要に応じて通話を転送および再ターゲットできるため、発信者が予期しない場所で通話が終了する可能性があると想定しています。これは、コールルーティングの一般的な条件です。この観察結果は、発信者が回答者の電話番号を予測する能力を制限するため、ソリューションスペースにとって重要です（「予期しない回答者」の問題の詳細については、[SIP-SECURITY]を参照してください）。
Furthermore, we assume that some intermediaries or gateways may, due to their capabilities or policies, discard calling party number information in whole or in part. Today, many IP-PSTN gateways simply ignore any information available about the caller in the IP leg of the call and allow the telephone number of the Primary Rate Interface (PRI) line used by the gateway to be sent as the calling party number for the PSTN leg of the call. For example, a call might also gateway to a multi-frequency network where only a limited number of digits of automatic numbering identification (ANI) data are signaled. Some protocols may render telephone numbers in a way that makes it impossible for a terminating side to parse or canonicalize a number. In these cases, providing authenticated calling number data may be impossible, but this is not indicative of an attack or other security failure.
さらに、一部の仲介者またはゲートウェイは、それらの機能またはポリシーにより、発呼者番号情報の全体または一部を破棄する可能性があると想定しています。今日、多くのIP-PSTNゲートウェイは、通話のIPレッグの発信者に関する利用可能な情報を単に無視し、ゲートウェイが使用する一次群速度インターフェース（PRI）回線の電話番号を、コールのPSTNレッグ。たとえば、コールは、自動周波数識別（ANI）データの限られた桁数のみが信号で送信されるマルチ周波数ネットワークへのゲートウェイになる場合もあります。一部のプロトコルでは、着信側が番号を解析または正規化できない方法で電話番号をレンダリングする場合があります。これらの場合、認証された発番号データを提供することは不可能かもしれませんが、これは攻撃または他のセキュリティの失敗を示すものではありません。
We assume that an attacker has the following capabilities:
攻撃者には次の能力があると想定しています。
o An attacker can create telephone calls at will, originating them either on the PSTN or over IP, and can supply an arbitrary calling party number.
o 攻撃者は、PSTNまたはIPを介して電話を発信し、任意の発呼者番号を提供できます。
o An attacker can capture and replay signaling previously observed by it.
o 攻撃者は、以前に観察したシグナリングをキャプチャして再生できます。
o An attacker has access to the Internet and thus the ability to inject arbitrary traffic over the Internet, to access public directories, etc.
o 攻撃者はインターネットにアクセスできるため、インターネットを介して任意のトラフィックを注入したり、パブリックディレクトリにアクセスしたりすることができます。
There are attack scenarios in which an attacker compromises intermediaries in the call path or captures credentials that allow the attacker to impersonate a caller. Those system-level attacks are not considered in this threat model, though secure design and operation of systems to prevent these sorts of attacks are necessary for envisioned countermeasures to work. To date, robocallers and other impersonators do not resort to compromising systems but rather exploit the intrinsic lack of secure identity in existing mechanisms; remedying this problem lies within the scope of this threat model.
攻撃者が呼び出しパスの仲介者を危険にさらしたり、攻撃者が呼び出し元になりすますことができる資格情報を取得したりする攻撃シナリオがあります。これらのシステムレベルの攻撃はこの脅威モデルでは考慮されていませんが、想定される対策が機能するには、この種の攻撃を防ぐためのシステムの安全な設計と運用が必要です。今日まで、ロボコーラーや他のなりすましは、システムを危険にさらすことなく、既存のメカニズムに安全なIDの本質的な欠如を利用しています。この問題の修正は、この脅威モデルの範囲内にあります。
This threat model also does not consider scenarios in which the operators of intermediaries or gateways are themselves adversaries who intentionally discard valid identity information (without a user requesting anonymity) or who send falsified identity; see Section 4.1.
この脅威モデルでは、仲介者またはゲートウェイのオペレーター自体が、（ユーザーが匿名性を要求せずに）有効なID情報を意図的に破棄したり、偽のIDを送信したりするシナリオも考慮されません。セクション4.1を参照してください。
The uses of impersonation described in this section are broadly divided into two categories: those where an attack will not succeed unless the attacker impersonates a specific identity and those where an attacker impersonates an arbitrary identity in order to disguise its own. At a high level, impersonation encourages targets to answer attackers' calls and makes identifying attackers more difficult. This section shows how concrete attacks based on those different techniques might be launched.
このセクションで説明する偽装の使用法は、大きく分けて2つのカテゴリに分類されます。攻撃者が特定のIDを偽装しない限り攻撃は成功しないものと、攻撃者が偽装して任意のIDを偽装するものです。高レベルでは、なりすましはターゲットが攻撃者の呼び出しに応答するように促し、攻撃者の特定をより困難にします。このセクションでは、これらのさまざまな手法に基づく具体的な攻撃がどのように行われるかを示します。
A voicemail service may allow users calling from their phones access to their voicemail boxes on the basis of the calling party number. If an attacker wants to access the voicemail of a particular target, the attacker may try to impersonate the calling party number using one of the scenarios described in Section 4.
ボイスメールサービスでは、電話をかけたユーザーが、発信者番号に基づいてボイスメールボックスにアクセスできる場合があります。攻撃者が特定のターゲットのボイスメールにアクセスしたい場合、攻撃者はセクション4で説明されているシナリオの1つを使用して、発呼者番号を偽装しようとする可能性があります。
This attack is closely related to attacks on similar automated systems, potentially including banks, airlines, calling-card services, conferencing providers, ISPs, and other businesses that fully or partly grant access to resources on the basis of the calling party number alone (rather than any shared secret or further identity check). It is analogous to an attack in which a human is encouraged to answer a phone or to divulge information once a call is in progress, by seeing a familiar calling party number.
この攻撃は、銀行、航空会社、テレホンカードサービス、会議プロバイダー、ISP、および発呼者番号のみに基づいてリソースへのアクセスを完全にまたは部分的に許可するその他のビジネスを含む可能性がある同様の自動化システムへの攻撃と密接に関連しています（むしろすべての共有シークレットまたは追加のアイデンティティチェックよりも）。これは、おなじみの発信者番号を確認することで、人間が電話に出たり、通話中に情報を漏らしたりすることを奨励する攻撃に似ています。
The envisioned countermeasures for this attack involve the voicemail system treating calls that supply authenticated calling number data differently from other calls. In the absence of that identity information, for example, a voicemail service might enforce some other caller authentication policy (perhaps requiring a PIN for caller authentication). Asserted caller identity alone provides an authenticated basis for granting access to a voicemail box only when an identity is claimed legitimately; the absence of a verifiably legitimate calling identity here may not be evidence of malice, just of uncertainty or a limitation imposed by the set of intermediaries traversed for a specific call path.
この攻撃に対する想定される対策には、認証済みの発番号データを提供する通話を他の通話とは異なる方法で処理するボイスメールシステムが含まれます。たとえば、その識別情報がない場合、ボイスメールサービスは他の発信者認証ポリシーを強制する可能性があります（おそらく発信者認証にPINが必要です）。アサートされた発信者IDのみが、IDが正当に要求された場合にのみ、ボイスメールボックスへのアクセスを許可するための認証された基盤を提供します。ここに検証可能な正当な呼び出しIDがないことは、悪意の証拠ではなく、特定の呼び出しパスを通過する仲介者のセットによって課せられた不確実性または制限の証拠である可能性があります。
If the voicemail service could learn ahead of time that it should expect authenticated calling number data from a particular number, that would enable the voicemail service to adopt stricter policies for handling a request without authentication data. Since users typically contact a voicemail service repeatedly, the service could, for example, remember which requests contain authenticated calling number data and require further authentication mechanisms when identity is absent. The deployment of such a feature would be facilitated in many environments by the fact that the voicemail service is often operated by an organization that would be in a position to enable or require authentication of calling party identity (for example, carriers or enterprises). Even if the voicemail service is decoupled from the number assignee, issuers of credentials or other authorities could provide a service that informs verifiers that they should expect identity in calls from particular numbers.
ボイスメールサービスが特定の番号からの認証された発信者番号データを予期する必要があることを事前に学習できた場合、ボイスメールサービスは認証データなしで要求を処理するためのより厳しいポリシーを採用できるようになります。ユーザーは通常ボイスメールサービスに繰り返し連絡するため、サービスは、たとえば、認証された発信者番号データを含む要求を記憶し、IDが存在しない場合に追加の認証メカニズムを必要とする可能性があります。このような機能の導入は、多くの環境でボイスメールサービスが多くの場合、発呼者のアイデンティティの認証を有効または要求する立場にある組織（キャリアや企業など）によって運用されるという事実によって促進されます。ボイスメールサービスが番号の割り当て先から切り離されている場合でも、資格情報の発行者または他の当局は、特定の番号からの呼び出しでIDを期待する必要があることを検証者に通知するサービスを提供できます。
The unsolicited commercial calling, or 'robocalling' for short, attack is similar to the voicemail attack except that the robocaller does not need to impersonate the particular number controlled by the target, merely some "plausible" number. A robocaller may impersonate a number that is not an assignable number (for example, in the United States, a number beginning with 0) or an unassigned number. This behavior is seen in the wild today. A robocaller may change numbers every time a new call is placed, e.g., selecting numbers randomly.
迷惑なコマーシャルコール（略して「ロボコール」）攻撃は、ボイスメール攻撃に似ていますが、ロボ発信者は、ターゲットによって制御される特定の番号を偽装する必要がなく、単に「もっともらしい」番号である必要があります。ロボ発信者は、割り当て可能な番号ではない番号（たとえば、米国では0で始まる番号）または割り当てられていない番号を偽装する場合があります。この振る舞いは今日の野生で見られます。ロボ発信者は、新しい番号がランダムに選択されるなど、新しい通話が発信されるたびに番号を変更することがあります。
A closely related attack is sending unsolicited bulk commercial messages via text messaging services. These messages usually originate on the Internet, though they may ultimately reach endpoints over traditional telephone network protocols or the Internet. While most text messaging endpoints are mobile phones, broadband residential services are increasingly supporting text messaging as well. The originators of these messages typically impersonate a calling party number, in some cases, a "short code" specific to text messaging services.
密接に関連する攻撃は、テキストメッセージサービスを介して迷惑な商用メッセージを送信することです。これらのメッセージは通常インターネットから発信されますが、最終的には従来の電話ネットワークプロトコルまたはインターネットを介してエンドポイントに到達する可能性があります。ほとんどのテキストメッセージングエンドポイントは携帯電話ですが、ブロードバンドレジデンシャルサービスもテキストメッセージングをますますサポートしています。これらのメッセージの発信者は、通常、発信者番号を偽装し、場合によっては、テキストメッセージングサービスに固有の「ショートコード」を偽装します。
The envisioned countermeasures to robocalling are similar to those in the voicemail example, but there are significant differences. One important potential countermeasure is simply to verify that the calling party number is in fact assignable and assigned. Unlike voicemail services, end users typically have never been contacted by the number used by a robocaller before. Thus, they can't rely on past association to anticipate whether or not the calling party number should supply authenticated calling number data. If there were a service that could inform the terminating side that it should expect this data for calls or texts from that number, however, that would also help in the robocalling case.
想定されるロボコールへの対策は、ボイスメールの例と同様ですが、大きな違いがあります。重要な潜在的な対策の1つは、発信者番号が実際に割り当て可能で割り当てられていることを確認することです。ボイスメールサービスとは異なり、通常、エンドユーザーはロボ発信者が使用する番号から連絡を受けたことはありません。したがって、発呼側番号が認証された発呼番号データを提供する必要があるかどうかを予測するために、過去の関連付けに依存することはできません。ただし、その番号からの通話またはテキストに対してこのデータを期待する必要があることを着信側に通知できるサービスがあった場合、それはロボコールの場合にも役立ちます。
When a human callee is to be alerted at call setup time, the time frame for executing any countermeasures is necessarily limited. Ideally, a user would not be alerted that a call has been received until any necessary identity checks have been performed. This could, however, result in inordinate post-dial delay from the perspective of legitimate callers. Cryptographic and network operations must be minimized for these countermeasures to be practical. For text messages, a delay for executing anti-impersonation countermeasures is much less likely to degrade perceptible service.
呼び出しのセットアップ時に人間の呼び出し先に警告する場合、対策を実行するための時間枠は必然的に制限されます。理想的には、必要なIDチェックが実行されるまで、コールが受信されたことがユーザーに通知されません。ただし、これにより、正当な発信者の観点からダイヤル後の過度の遅延が発生する可能性があります。これらの対策を実用的にするには、暗号化およびネットワーク操作を最小限に抑える必要があります。テキストメッセージの場合、偽装対策の実行が遅れても、知覚可能なサービスが低下する可能性ははるかに低くなります。
The eventual effect of these countermeasures would be to force robocallers to either (a) block their caller identity, in which case end users could opt not to receive such calls or messages, or (b) use authenticated calling numbers traceable to them, which would then allow for other forms of redress.
これらの対策の最終的な効果は、ロボ発信者に（a）発信者IDをブロックするように強制することです。この場合、エンドユーザーはそのような通話やメッセージを受信しないことを選択できます。または（b）追跡可能な認証された発信者番号を使用します。次に、他の形の救済を考慮します。
In the case of telephony denial-of-service (TDoS) attacks, the attack relies on impersonation in order to obscure the origin of an attack that is intended to tie up telephone resources. By placing incessant telephone calls, an attacker renders a target number unreachable by legitimate callers. These attacks might target a business, an individual, or a public resource like emergency responders; the attacker may intend to extort the target. Attack calls may be placed from a single endpoint or from multiple endpoints under the control of the attacker, and the attacker may control endpoints in different administrative domains. Impersonation, in this case, allows the attack to evade policies that would block based on the originating number and furthermore prevents the victim from learning the perpetrator of the attack or even the originating service provider of the attacker.
テレフォニーサービス拒否（TDoS）攻撃の場合、攻撃は、電話リソースを拘束することを目的とした攻撃の発信元を隠すために、なりすましに依存します。攻撃者は絶え間なく電話をかけることにより、正当な発信者がターゲット番号に到達できないようにします。これらの攻撃は、企業、個人、または緊急対応者などの公共のリソースを標的とする可能性があります。攻撃者はターゲットを強要しようとする可能性があります。攻撃呼び出しは、単一のエンドポイントから、または攻撃者の制御下にある複数のエンドポイントから行われる可能性があり、攻撃者は異なる管理ドメインのエンドポイントを制御する可能性があります。この場合、なりすましにより、攻撃は発信元の番号に基づいてブロックするポリシーを回避し、さらに被害者が攻撃の実行者または攻撃者の発信元のサービスプロバイダーさえ知ることを防ぎます。
As is the case with robocalling, the attacker typically does not have to impersonate a specific number in order to launch a denial-of-service attack. The number simply has to vary enough to prevent simple policies from blocking the attack calls. An attacker may, however, have a further intention to create the appearance that a particular party is to blame for an attack; in that case, the attacker might want to impersonate a secondary target in the attack.
ロボコールの場合と同様に、攻撃者は通常、サービス拒否攻撃を開始するために特定の番号を偽装する必要はありません。この数は、単純なポリシーが攻撃の呼び出しをブロックするのを防ぐために、十分に異なる必要があります。ただし、攻撃者は、特定の当事者が攻撃のせいにしているように見せかけるためにさらに意図を持っている場合があります。その場合、攻撃者は攻撃のセカンダリターゲットになりすまそうとします。
The envisioned countermeasures are twofold. First, as with robocalling, ensuring that calling party numbers are assignable or assigned will help mitigate unsophisticated attacks. Second, if authenticated calling number data is supplied for legitimate calls, then Internet endpoints or intermediaries can make effective policy decisions in the middle of an attack by deprioritizing unsigned calls when congestion conditions exist; signed calls, if accepted, have the necessary accountability should it turn out they are malicious. This could extend to include, for example, an originating network observing a congestion condition for a destination number and perhaps dropping unsigned calls that are clearly part of a TDoS attack. As with robocalling, all of these countermeasures must execute in a timely manner to be effective.
想定される対策は2つあります。まず、ロボコールの場合と同様に、発信者番号が割り当て可能または割り当てられていることを確認すると、高度な攻撃を軽減できます。第2に、認証された発信者番号データが正当な通話に提供された場合、輻輳状態が存在する場合、インターネットエンドポイントまたは仲介者は、署名されていない通話の優先順位を下げることにより、攻撃の途中で効果的なポリシー決定を行うことができます。署名された呼び出しは、受け入れられた場合、悪意があることが判明した場合に必要な責任を負います。これは、たとえば、発信元ネットワークが宛先番号の輻輳状態を監視し、おそらくTDoS攻撃の一部である署名されていないコールをドロップすることを含むように拡張できます。ロボコールと同様に、これらの対策はすべて、効果的に実行するためにタイムリーに実行する必要があります。
There are certain flavors of TDoS attacks, including those against emergency responders, against which authenticated calling number data is unlikely to be a successful countermeasure. These entities are effectively obligated to attempt to respond to every call they receive, and the absence of authenticated calling number data in many cases will not remove that obligation.
TDoS攻撃には、特定のフレーバーがあり、緊急応答者に対するものを含めて、認証された発信者番号データが有効な対策になるとは考えられません。これらのエンティティは、受け取ったすべての通話に応答するように試みる義務が事実上あり、多くの場合、認証された発信者番号データがなくてもその義務は取り除かれません。
The examples that follow rely on Internet protocols including SIP [RFC3261] and WebRTC [RTCWEB-OVERVIEW].
以下の例は、SIP [RFC3261]およびWebRTC [RTCWEB-OVERVIEW]を含むインターネットプロトコルに依存しています。
Impersonation, IP-IP
偽装、IP-IP
An attacker with an IP phone sends a SIP request to an IP-enabled voicemail service. The attacker puts a chosen calling party number into the From header field value of the INVITE. When the INVITE reaches the endpoint terminal, the terminal renders the attacker's chosen calling party number as the calling identity.
IP電話を持つ攻撃者は、IP対応のボイスメールサービスにSIPリクエストを送信します。攻撃者は、選択した発呼者番号をINVITEのFromヘッダーフィールド値に入力します。 INVITEがエンドポイントターミナルに到達すると、ターミナルは攻撃者が選択した発呼者番号を発呼IDとしてレンダリングします。
Impersonation, PSTN-PSTN
偽装、PSTN-PSTN
An attacker with a traditional Private Branch Exchange (PBX) (connected to the PSTN through ISDN) sends a Q.931 SETUP request [Q931] with a chosen calling party number, which a service provider inserts into the corresponding SS7 [Q764] calling party number (CgPN) field of a call setup message (Initial Address Message (IAM)). When the call setup message reaches the endpoint switch, the terminal renders the attacker's chosen calling party number as the calling identity.
ISDNを介してPSTNに接続された従来の構内交換機（PBX）を持つ攻撃者は、選択された発呼者番号を含むQ.931 SETUP要求[Q931]を送信します。これは、サービスプロバイダーが対応するSS7 [Q764]発呼者に挿入します。コールセットアップメッセージ（初期アドレスメッセージ（IAM））の番号（CgPN）フィールド。コールセットアップメッセージがエンドポイントスイッチに到達すると、端末は攻撃者が選択した発番号を発呼IDとしてレンダリングします。
Impersonation, IP-PSTN
偽装、IP-PSTN
An attacker on the Internet uses a commercial WebRTC service to send a call to the PSTN with a chosen calling party number. The service contacts an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the SS7 [Q764] call setup message (the CgPN field of an IAM). When the call setup message reaches the terminating telephone switch, the terminal renders the attacker's chosen calling party number as the calling identity.
インターネット上の攻撃者は、商用のWebRTCサービスを使用して、選択された発番号でPSTNに通話を送信します。このサービスは、インターネットからPSTNへのゲートウェイに接続し、攻撃者が選択した発呼者番号をSS7 [Q764]コールセットアップメッセージ（IAMのCgPNフィールド）に挿入します。通話設定メッセージが着信側の電話交換機に到達すると、端末は攻撃者が選択した発呼者番号を発呼IDとしてレンダリングします。
Impersonation, IP-PSTN-IP
偽装、IP-PSTN-IP
An attacker with an IP phone sends a SIP request to the telephone number of a voicemail service, perhaps without even knowing that the voicemail service is IP-based. The attacker puts a chosen calling party number into the From header field value of the INVITE. The attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts the attacker's chosen calling party number into the CgPN of an IAM. That IAM then traverses the PSTN until (perhaps after a call forwarding) it reaches another gateway, this time back to the IP realm, to an H.323 network. The PSTN-IP gateway takes the calling party number in the IAM CgPN field and puts it into the SETUP request. When the SETUP reaches the endpoint terminal, the terminal renders the attacker's chosen calling party number as the calling identity.
IP電話を持つ攻撃者は、おそらくボイスメールサービスがIPベースであることさえ知らなくても、ボイスメールサービスの電話番号にSIP要求を送信します。攻撃者は、選択した発呼者番号をINVITEのFromヘッダーフィールド値に入力します。攻撃者のINVITEは、インターネットからPSTNへのゲートウェイに到達します。ゲートウェイは、攻撃者が選択した発呼者番号をIAMのCgPNに挿入します。次に、そのIAMはPSTNを通過して（おそらくコール転送の後で）別のゲートウェイに到達し、今度はIPレルムに戻ってH.323ネットワークに戻ります。 PSTN-IPゲートウェイは、IAM CgPNフィールドの発信者番号を取得し、それをSETUPリクエストに入れます。 SETUPがエンドポイント端末に到達すると、端末は攻撃者が選択した発呼者番号を発呼IDとしてレンダリングします。
Solution-specific attacks are outside the scope of this document, though two sorts of solutions are anticipated by the STIR problem statement: in-band and out-of-band solutions (see [RFC7340]). There are a few points that future work on solution-specific threats must acknowledge. The design of the credential system envisioned as a solution to these threats must, for example, limit the scope of the credentials issued to carriers or national authorities to those numbers that fall under their purview. This will impose limits on what (verifiable) assertions can be made by intermediaries.
ソリューション固有の攻撃はこのドキュメントの範囲外ですが、STIR問題ステートメントでは、インバンドソリューションとアウトオブバンドソリューションの2種類のソリューションが予想されます（[RFC7340]を参照）。ソリューション固有の脅威に関する今後の取り組みで認めなければならない点がいくつかあります。これらの脅威の解決策として想定されている資格情報システムの設計は、たとえば、キャリアまたは国家当局に発行される資格情報の範囲を、彼らの範囲に該当する数に制限する必要があります。これにより、仲介者が行うことができる（検証可能な）アサーションに制限が課されます。
Some of the attacks that should be considered in the future include the following:
将来考慮すべき攻撃には、次のようなものがあります。
o Attacks against in-band solutions
o インバンドソリューションに対する攻撃
* Replaying parts of messages used by the solution
* ソリューションで使用されるメッセージの一部を再生する
* Using a SIP REFER request to induce a party with access to credentials to place a call to a chosen number
* SIP REFER要求を使用して、資格情報へのアクセス権を持つ当事者に誘導して、選択した番号に電話をかける
* Removing parts of messages used by the solution
* ソリューションで使用されるメッセージの一部を削除する
o Attacks against out-of-band solutions
o 帯域外ソリューションに対する攻撃
* Provisioning false or malformed data reflecting a placed call into any datastores that are part of the out-of-band mechanism
* アウトオブバンドメカニズムの一部であるデータストアへの発信を反映した、誤った形式または不正な形式のデータのプロビジョニング
* Mining any datastores that are part of the out-of-band mechanism
* アウトオブバンドメカニズムの一部であるデータストアのマイニング
o Attacks against either approach
o どちらのアプローチに対する攻撃
* Attack on any directories/services that report whether you should expect authenticated calling number data or not
* 認証された発番号データを期待するべきかどうかを報告するディレクトリ/サービスへの攻撃
* Canonicalization attacks
* 正規化攻撃
This document provides a threat model and is thus entirely about security.
このドキュメントは脅威モデルを提供しているため、完全にセキュリティに関するものです。
[OMTP-VV] Open Mobile Terminal Platform, "Visual Voice Mail Interface Specification", Version 1.3, June 2010, <http://www.gsma.com/newsroom/wp-content/uploads/2012/07/ OMTP_VVM_Specification_1_3.pdf>.
[OMTP-VV] Open Mobile Terminal Platform、 "Visual Voice Mail Interface Specification"、Version 1.3、2010年6月、<http://www.gsma.com/newsroom/wp-content/uploads/2012/07/ OMTP_VVM_Specification_1_3.pdf >。
[Q764] ITU, "Signalling System No. 7 - ISDN User Part signalling procedures", Recommendation ITU-T Q.764, December 1999, <http://www.itu.int/rec/T-REC-Q.764/>.
[Q764] ITU、「Signalling System No. 7-ISDN User Part Signaling Procedures」、Recommendation ITU-T Q.764、December 1999、<http://www.itu.int/rec/T-REC-Q.764 />。
[Q931] ITU, "ISDN user-network interface layer 3 specification for basic call control", Recommendation ITU-T Q.931, May 1998, <http://www.itu.int/rec/T-REC-Q.931/>.
[Q931] ITU、「基本的な呼制御のためのISDNユーザーネットワークインターフェイスレイヤー3仕様」、勧告ITU-T Q.931、1998年5月、<http://www.itu.int/rec/T-REC-Q。 931 />。
[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, <http://www.rfc-editor.org/rfc/rfc3261.txt>.
[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月、<http://www.rfc-editor.org/rfc/rfc3261.txt>。
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, September 2014, <http://www.rfc-editor.org/info/rfc7340>.
[RFC7340] Peterson、J.、Schulzrinne、H。、およびH. Tschofenig、「Secure Telephone Identity Problem Statement and Requirements」、RFC 7340、2014年9月、<http://www.rfc-editor.org/info/rfc7340 >。
[RTCWEB-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-12, October 2014.
[RTCWEB-OVERVIEW] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-ietf-rtcweb-overview-12、2014年10月。
[SIP-SECURITY] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, draft-peterson-sipping-retarget-00, February 2005.
[SIP-SECURITY] Peterson、J。、「SIPのリターゲティングとセキュリティ：フレームワークと要件」、進行中の作業、draft-peterson-sipping-retarget-00、2005年2月。
Acknowledgments
謝辞
Sanjay Mishra, David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen, Alex Bobotek, Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings, and Eric Rescorla provided key input to the discussions leading to this document.
Sanjay Mishra、David Frankel、Penn Pfautz、Stephen Kent、Brian Rosen、Alex Bobotek、Henning Schulzrinne、Hannes Tschofenig、Cullen Jennings、およびEric Rescorlaは、このドキュメントに至る議論に重要な情報を提供しました。
Author's Address
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 United States
Jon Peterson NeuStar、Inc. 1800 Sutter St. Suite 570 Concord、CA 94520アメリカ合衆国
EMail: jon.peterson@neustar.biz