[要約] RFC 5069は、緊急通報のマーキングとマッピングのためのセキュリティの脅威と要件についての情報を提供しています。このRFCの目的は、緊急通報システムのセキュリティを向上させ、適切な対策を講じるためのガイドラインを提供することです。

Network Working Group                                     T. Taylor, Ed.
Request for Comments: 5069                                        Nortel
Category: Informational                                    H. Tschofenig
                                                  Nokia Siemens Networks
                                                          H. Schulzrinne
                                                     Columbia University
                                                            M. Shanmugam
                                                                 Detecon
                                                            January 2008
        

Security Threats and Requirements for Emergency Call Marking and Mapping

緊急コールマーキングとマッピングのセキュリティの脅威と要件

Status of This Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Abstract

概要

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.

このドキュメントでは、シグナリングメッセージのマーキングに関連するセキュリティの脅威をレビューして、それらが緊急事態に関連していることを示し、場所をマッピングするプロセスで、公共安全の回答ポイント(PSAP)をポイントするユニバーサルリソース識別子(URI)にマッピングします。このマッピングは、IPネットワークを介して緊急通話をルーティングするプロセスの一部として発生します。

Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls.

特定された脅威に基づいて、このドキュメントは、マッピングプロトコルと緊急マークコールの処理のための一連のセキュリティ要件を確立します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Marking, Mapping, and the Emergency Call Routing Process . . .  3
     3.1.  Call Marking . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Mapping  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Objectives of Attackers  . . . . . . . . . . . . . . . . . . .  4
   5.  Potential Attacks  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Attacks Involving the Emergency Identifier . . . . . . . .  5
     5.2.  Attacks Against or Using the Mapping Process . . . . . . .  5
       5.2.1.  Attacks Against the Emergency Response System  . . . .  6
       5.2.2.  Attacks to Prevent a Specific Individual from
               Receiving Aid  . . . . . . . . . . . . . . . . . . . .  7
       5.2.3.  Attacks to Gain Information about an Emergency . . . .  7
   6.  Security Requirements Relating to Emergency Marking and
       Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
        
1. Introduction
1. はじめに

Legacy telephone network users can summon help for emergency services (such as an ambulance, the fire department, and the police) using a well known number (e.g., 911 in North America, 112 in Europe). A key factor in the handling of such calls is the ability of the system to determine caller location and to route the call to the appropriate Public Safety Answering Point (PSAP) based on that location. With the introduction of IP-based telephony and multimedia services, support for emergency calling via the Internet also has to be provided. Two core components of IP-based emergency calling include an emergency service identifier and a mapping protocol. The emergency service identifier indicates that the call signaling establishes an emergency call, while the mapping protocol translates the emergency service identifier and the caller's geographic location into an appropriate PSAP URL.

レガシー電話ネットワークのユーザーは、よく知られている数(北米では911、ヨーロッパでは112)を使用して、救急サービス(救急車、消防署、警察など)のヘルプを召喚できます。このような呼び出しの処理における重要な要素は、システムが発信者の場所を決定し、その場所に基づいて適切な公共安全応答ポイント(PSAP)にコールをルーティングする能力です。IPベースのテレフォニーとマルチメディアサービスの導入により、インターネット経由の緊急通話のサポートも提供する必要があります。IPベースの緊急通話の2つのコアコンポーネントには、緊急サービス識別子とマッピングプロトコルが含まれます。緊急サービス識別子は、コールシグナリングが緊急コールを確立することを示し、マッピングプロトコルは緊急サービス識別子と発信者の地理的位置を適切なPSAP URLに変換します。

Attacks against the Public Switched Telephone Network (PSTN) have taken place for decades. The Internet is seen as an even more hostile environment. Thus, it is important to understand the types of attacks that might be mounted against the infrastructure providing emergency services and to develop security mechanisms to counter those attacks. While this can be a broad topic, the present document restricts itself to attacks on the mapping of locations to PSAP URIs and attacks based on emergency marking. Verification by the PSAP operator of the truthfulness of a reported incident and various other attacks against the PSAP infrastructure related to the usage of faked location information are outside the scope of the document.

公共の切り替えた電話網(PSTN)に対する攻撃は、数十年にわたって行われてきました。インターネットはさらに敵対的な環境と見なされています。したがって、緊急サービスを提供するインフラストラクチャに対してマウントされる可能性のある攻撃の種類を理解し、それらの攻撃に対抗するためのセキュリティメカニズムを開発することが重要です。これは幅広いトピックになる可能性がありますが、現在のドキュメントは、PSAP URIへの場所のマッピングと、緊急マーキングに基づく攻撃に対する攻撃に制限されています。報告された事件の真実性のPSAPオペレーターによる検証および偽造位置情報の使用に関連するPSAPインフラストラクチャに対する他のさまざまな攻撃は、ドキュメントの範囲外です。

This document is organized as follows: Section 2 describes basic terminology. Section 3 briefly describes how emergency marking and mapping fit within the process of routing emergency calls. Section 4 describes some motivations of attackers in the context of emergency calling, Section 5 describes and illustrates the attacks that might be used, and Section 6 lists the security-related requirements that must be met if these attacks are to be mitigated.

このドキュメントは次のように整理されています。セクション2では、基本的な用語について説明します。セクション3では、緊急通話をルーティングするプロセス内で緊急マーキングとマッピングがどのように適合するかについて簡単に説明します。セクション4では、緊急呼び出しの文脈で攻撃者の動機を説明し、セクション5で使用される可能性のある攻撃について説明および説明し、セクション6では、これらの攻撃を軽減する場合に満たす必要があるセキュリティ関連の要件をリストします。

2. Terminology
2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119], with the qualification that unless otherwise stated, they apply to the design of the mapping protocol, not its implementation or application.

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているとおりに解釈するために、特に明記しない限り、実装やアプリケーションではなくマッピングプロトコルの設計に適用されるという資格とともに。

The terms "call taker", "mapping service", "emergency caller", "emergency identifier", "mapping", "mapping client", "mapping server", "mapping protocol", and "Public Safety Answering Point (PSAP)" are taken from [RFC5012].

「コールテイカー」、「マッピングサービス」、「緊急発信者」、「緊急識別子」、「マッピング」、「マッピングクライアント」、「マッピングサーバー」、「マッピングプロトコル」、および「公共安全対応ポイント(PSAP)という用語「[RFC5012]から取られています。

The term "location information" is taken from RFC 3693 [RFC3693].

「位置情報」という用語は、RFC 3693 [RFC3693]から取得されます。

The term "emergency caller's device" designates the IP host closest to the emergency caller in the signalling path between the emergency caller and the PSAP. Examples include an IP phone running SIP, H.323, or a proprietary signalling protocol, a PC running a soft client or an analogue terminal adapter, or a residential gateway controlled by a softswitch.

「緊急発信者のデバイス」という用語は、緊急発信者とPSAPの間のシグナリングパスで緊急発信者に最も近いIPホストを指定します。例には、SIPを実行しているIP電話、H.323、または独自のシグナリングプロトコル、ソフトクライアントまたはアナログ端子アダプターを実行しているPC、またはソフトスイッチによって制御される住宅ゲートウェイが含まれます。

3. Marking, Mapping, and the Emergency Call Routing Process
3. マーキング、マッピング、および緊急通話ルーティングプロセス

This memo deals with two topics relating to the routing of emergency calls to their proper destination: call marking and mapping.

このメモは、適切な目的地への緊急通話のルーティングに関する2つのトピック、つまり呼び出しマーキングとマッピングを扱います。

3.1. Call Marking
3.1. マーキングを呼び出します

Marking of call signalling enables entities along the signalling path to recognize that a particular signalling message is associated with an emergency call. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing.

コールシグナリングのマーキングにより、シグナリングパスに沿ったエンティティが特定のシグナリングメッセージが緊急コールに関連付けられていることを認識できます。緊急識別子を含むシグナル伝達には、優先処理、特別な処理、および/または特別なルーティングが与えられます。

3.2. Mapping
3.2. マッピング

An important goal of emergency call routing is to ensure that any emergency call is routed to a PSAP. Preferably, the call is routed to the PSAP responsible for the caller's location, since misrouting consumes valuable time while the call taker locates and forwards the call to the right PSAP. As described in [RFC5012], mapping is part of the process of achieving this preferable outcome.

緊急コールルーティングの重要な目標は、緊急通話がPSAPにルーティングされるようにすることです。できれば、コールは、コールテイカーが正しいPSAPへのコールを見つけて転送する間、誤った誤った時間を消費するため、呼び出し者の位置の責任を負うPSAPにルーティングされます。[RFC5012]で説明されているように、マッピングはこの好ましい結果を達成するプロセスの一部です。

In brief, mapping involves a mapping client, a mapping server, and the protocol that passes between them. The protocol allows the client to pass location information to the mapping server and to receive back a URI, which can be used to direct call signalling to a PSAP.

簡単に言えば、マッピングには、マッピングクライアント、マッピングサーバー、およびそれらの間を通過するプロトコルが含まれます。このプロトコルにより、クライアントは位置情報をマッピングサーバーに渡すことができ、URIを受け取ることができます。URIは、PSAPにコールシグナル伝達を向けるために使用できます。

4. Objectives of Attackers
4. 攻撃者の目的

Attackers may direct their efforts either against a portion of the emergency response system or against an individual. Attacks against the emergency response system have three possible objectives:

攻撃者は、緊急対応システムの一部または個人に対して努力を向けることができます。緊急対応システムに対する攻撃には、3つの可能な目的があります。

o to deny system services to all users in a given area. The motivation may range from thoughtless vandalism, to wide-scale criminality, to terrorism. One interesting variant on this motivation is the case where a victim of a large emergency hopes to gain faster service by blocking others' competing calls for help.

o 特定の領域のすべてのユーザーにシステムサービスを拒否します。動機は、思慮のない破壊行為から、幅広い犯罪、テロリズムまで、さまざまです。この動機に関する興味深い変種の1つは、大規模な緊急事態の犠牲者が、他人の競合する競合する呼び出しをブロックすることでより速いサービスを得ることを望んでいる場合です。

o to gain fraudulent use of services, by using an emergency identifier to bypass normal authentication, authorization, and accounting procedures.

o 緊急識別子を使用して通常の認証、承認、会計手順をバイパスすることにより、サービスの不正な使用を獲得するため。

o to divert emergency calls to non-emergency sites. This is a form of a denial-of-service attack similar to the first item, but quite likely more confusing for the caller himself or herself since the caller expects to talk to a PSAP operator but instead gets connected to someone else.

o 非緊急サイトへの緊急電話を迂回させる。これは、最初の項目と同様のサービス拒否攻撃の形式ですが、発信者はPSAPオペレーターと話すことを期待しているが、代わりに他の人とつながることを期待しているため、発信者自身にとってより混乱する可能性が高いです。

Attacks against an individual fall into two classes:

個人に対する攻撃は2つのクラスに分類されます。

o attacks to prevent an individual from receiving aid.

o 個人が援助を受けるのを防ぐための攻撃。

o attacks to gain information about an emergency that can be applied either against an individual involved in that emergency or to the profit of the attacker.

o その緊急事態に関与する個人または攻撃者の利益のいずれかに対して適用できる緊急事態に関する情報を得るための攻撃。

5. Potential Attacks
5. 潜在的な攻撃
5.1. Attacks Involving the Emergency Identifier
5.1. 緊急識別子を含む攻撃

The main possibility of attack involves use of the emergency identifier to bypass the normal procedures in order to achieve fraudulent use of services. An attack of this sort is possible only if the following conditions are true:

攻撃の主な可能性には、サービスの不正な使用を達成するために、通常の手順をバイパスするための緊急識別子の使用が含まれます。この種の攻撃は、次の条件が真である場合にのみ可能です。

a. The attacker is the emergency caller.

a. 攻撃者は緊急発信者です。

b. The call routing system assumes that the emergency caller's device signals the correct PSAP URI for the caller's location.

b. コールルーティングシステムは、緊急発信者のデバイスが発信者の場所の正しいPSAP URIを信号することを前提としています。

c. The call enters the domain of a service provider, which accepts it without applying normal procedures for authentication and authorization because the signalling carries the emergency identifier.

c. コールはサービスプロバイダーのドメインに入ります。これは、信号が緊急識別子を運ぶため、認証と承認のために通常の手順を適用せずに受け入れます。

d. The service provider routes the call according to the called address (e.g., SIP Request-URI), without verifying that this is the address of a PSAP (noting that a URI by itself does not indicate the nature of the entity it is pointing to).

d. サービスプロバイダーは、これがPSAPのアドレスであることを確認することなく、呼び出し中のアドレス(例:SIP Request-URIなど)に従って通話をルーティングします(URI自体が指摘しているエンティティの性質を示していないことに注意してください)。

If these conditions are satisfied, the attacker can bypass normal service provider authorization procedures for arbitrary destinations, simply by reprogramming the emergency caller's device to add the emergency identifier to non-emergency call signalling. In this case, the call signalling most likely will not include any location information, or there could be location information, but it is false.

これらの条件が満たされている場合、攻撃者は、緊急発信者のデバイスを再プログラミングして緊急識別子を非緊急コールシグナリングに追加するだけで、任意の目的地の通常のサービスプロバイダー認証手順をバイパスできます。この場合、コールシグナリングには位置情報が含まれない可能性が高いか、位置情報がある可能性がありますが、それは間違っています。

An attacker wishing to disrupt the emergency call routing system may use a similar technique to target components of that system for a denial-of-service attack. The attacker will find this attractive to reach components that handle emergency calls only. Flooding attacks are the most likely application of the technique, but it may also be used to identify target components for other attacks by analyzing the content of responses to the original signalling messages.

緊急コールルーティングシステムを混乱させたい攻撃者は、同様の手法を使用して、サービス拒否攻撃のためにそのシステムのコンポーネントをターゲットにすることができます。攻撃者は、緊急通話のみを処理するコンポーネントに到達するのに魅力的であると感じるでしょう。洪水攻撃はこの手法の最も可能性の高いアプリケーションですが、元のシグナリングメッセージへの応答の内容を分析することにより、他の攻撃のターゲットコンポーネントを識別するためにも使用できます。

5.2. Attacks Against or Using the Mapping Process
5.2. マッピングプロセスに対する攻撃または使用

This section describes classes of attacks involving the mapping process that could be used to achieve the attacker goals described in Section 4.

このセクションでは、セクション4で説明されている攻撃者の目標を達成するために使用できるマッピングプロセスを含む攻撃のクラスについて説明します。

5.2.1. Attacks Against the Emergency Response System
5.2.1. 緊急対応システムに対する攻撃

This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. If the mapping operation is disabled, then the emergency caller's device might not have the correct PSAP URI. As a consequence, the probability that emergency calls will be routed to the wrong PSAP increases. In the worst case, the emergency caller's device might not be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a double consequence: emergency response to the affected calls is delayed, and PSAP call taker resources outside the immediate area of the emergency are consumed due to the extra effort required to redirect the calls. Alternatively, attacks that cause the client to receive a URI that does not lead to a PSAP have the immediate effect of causing emergency calls to fail.

このセクションでは、特定の領域のすべての発信者の緊急対応システムの有効性を減らすことを目的とした攻撃を検討します。マッピング操作が無効になっている場合、緊急発信者のデバイスには正しいPSAP URIがない場合があります。結果として、緊急コールが間違ったPSAPにルーティングされる確率が増加します。最悪の場合、緊急発信者のデバイスはPSAP URIをまったく取得できない可能性があります。間違ったPSAPへのルーティングには二重の結果があります。影響を受けるコールへの緊急対応が遅れ、PSAPコールは、緊急事態のすぐ外の外側のテイカーリソースが消費されます。あるいは、PSAPにつながらないURIをクライアントに受信させる攻撃は、緊急コールを失敗させるという即時の効果があります。

Three basic attacks on the mapping process can be identified: denial of service, impersonation of the mapping server, or corruption of the mapping database. Denial of service can be achieved in several ways:

マッピングプロセスに対する3つの基本的な攻撃を特定できます:サービスの拒否、マッピングサーバーのなりすまし、またはマッピングデータベースの破損。サービスの拒否はいくつかの方法で達成できます。

o by a flooding attack on the mapping server;

o マッピングサーバーへの洪水攻撃により。

o by taking control of the mapping server and either preventing it from responding or causing it to send incorrect responses; or

o マッピングサーバーを制御し、応答するのを防ぐか、誤った応答を送信するようにすることにより。また

o by taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block them. An adversary may also attempt to modify the mapping protocol signalling messages. Additionally, the adversary may be able to replay past communication exchanges to fool an emergency caller by returning incorrect results.

o マッピングクエリと応答が通過する中間ノード(たとえば、ルーターなど)を制御し、そのコントロールを使用してそれらをブロックします。敵は、マッピングプロトコルシグナル伝達メッセージの変更を試みる場合もあります。さらに、敵は過去のコミュニケーション交換を再生して、誤った結果を返すことで緊急発信者を欺くことができるかもしれません。

In an impersonation attack, the attacker induces the mapping client to direct its queries to a host under the attacker's control rather than the real mapping server, or the attacker suppresses the response from the real mapping server and sends a spoofed response.

なりすまし攻撃では、攻撃者はマッピングクライアントに、実際のマッピングサーバーではなく攻撃者のコントロールの下でホストにクエリを向けるように誘導します。攻撃者は、実際のマッピングサーバーからの応答を抑制し、スプーフィングされた応答を送信します。

The former type of impersonation attack itself is an issue of mapping server discovery rather than the mapping protocol directly. However, the mapping protocol may allow impersonation to be detected, thereby preventing acceptance of responses from an impersonating entity and possibly triggering a more secure discovery procedure.

以前のタイプのなりすまし攻撃自体は、マッピングプロトコルではなく、サーバーの発見をマッピングする問題です。ただし、マッピングプロトコルでは、なりすましが検出される可能性があり、それにより、なりすましの実体からの回答の受け入れを防ぎ、より安全な発見手順を引き起こす可能性があります。

Corruption of the mapping database cannot be mitigated directly by mapping protocol design. Once corruption has been detected, the mapping protocol may have a role to play in determining which records have been corrupted.

マッピングデータベースの破損は、マッピングプロトコル設計によって直接軽減することはできません。破損が検出されると、マッピングプロトコルは、どのレコードが破損しているかを決定する上で役割を果たす可能性があります。

Beyond these attacks on the mapping operation itself, it is possible to use mapping to attack other entities. One possibility is that mapping clients are misled into sending mapping queries to the target of the attack instead of the mapping server. Prevention of such an attack is an operational issue rather than one of protocol design. Another possible attack is where the mapping server is tricked into sending responses to the target of the attack through spoofing of the source address in the query.

マッピング操作自体に対するこれらの攻撃を超えて、マッピングを使用して他のエンティティを攻撃することができます。1つの可能性は、マッピングクライアントがマッピングサーバーの代わりにマッピングクエリを攻撃のターゲットに送信することに誤解されていることです。このような攻撃の予防は、プロトコル設計ではなく運用上の問題です。別の可能な攻撃は、マッピングサーバーがクエリ内のソースアドレスのスプーフィングを通じて攻撃のターゲットに応答を送信するようにだまされます。

5.2.2. Attacks to Prevent a Specific Individual from Receiving Aid
5.2.2. 特定の個人が援助を受けるのを防ぐための攻撃

If an attacker wishes to deny emergency service to a specific individual, the mass attacks described in Section 5.2.1 will obviously work provided that the target individual is within the affected population. Except for the flooding attack on the mapping server, the attacker can in theory limit these attacks to the target, but this requires extra effort that the attacker is unlikely to expend. If the attacker is using a mass attack but does not wish to have too broad an effect, it is more likely to attack for a carefully limited period of time.

攻撃者が特定の個人への緊急サービスを拒否したい場合、セクション5.2.1で説明されている大量攻撃は、ターゲットの個人が影響を受ける母集団内にいる場合、明らかに機能します。マッピングサーバーへの洪水攻撃を除き、攻撃者は理論的にはこれらの攻撃をターゲットに制限できますが、これには攻撃者が消費する可能性が低いため、特別な努力が必要です。攻撃者が大量攻撃を使用しているが、あまりにも幅広い効果を持ちたくない場合、慎重に限られた期間攻撃する可能性が高くなります。

If the attacker wants to be selective, however, it may make more sense to attack the mapping client rather than the mapping server. This is particularly so if the mapping client is the emergency caller's device. The choices available to the attacker are similar to those for denial of service on the server side:

ただし、攻撃者が選択的になりたい場合は、マッピングサーバーではなくマッピングクライアントを攻撃する方が理にかなっている場合があります。これは、マッピングクライアントが緊急発信者のデバイスである場合に特にそうです。攻撃者が利用できる選択肢は、サーバー側のサービス拒否の選択肢に似ています。

o a flooding attack on the mapping client;

o マッピングクライアントへの洪水攻撃。

o taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block or modify them.

o マッピングクエリと応答が通過する中間ノード(たとえば、ルーター)の制御を取得し、そのコントロールを使用してそれらをブロックまたは変更します。

Taking control of the mapping client is also a logical possibility, but raises no issues for the mapping protocol.

マッピングクライアントを制御することも論理的な可能性ですが、マッピングプロトコルに問題は発生しません。

5.2.3. Attacks to Gain Information about an Emergency
5.2.3. 緊急事態に関する情報を得るための攻撃

This section discusses attacks used to gain information about an emergency. The attacker may be seeking the location of the caller (e.g., to effect a criminal attack). Alternatively, the attacker may be seeking information that could be used to link an individual (the caller or someone else involved in the emergency) with embarrassing information related to the emergency (e.g., "Who did the police take away just now?"). Finally, the attacker could be seeking to profit from the emergency, perhaps by offering his or her services (e.g., a news reporter, or a lawyer aggressively seeking new business).

このセクションでは、緊急事態に関する情報を得るために使用される攻撃について説明します。攻撃者は、発信者の場所を求めている可能性があります(たとえば、犯罪攻撃を実施するため)。あるいは、攻撃者は、個人(発信者または緊急事態に関係する他の誰か)を緊急事態に関連する恥ずかしい情報(たとえば、「今すぐ警察を奪ったのは誰ですか?」)をリンクするために使用できる情報を求めている場合があります。最後に、攻撃者は、おそらく彼または彼女のサービスを提供することで、緊急事態から利益を得ようとしている可能性があります(たとえば、ニュースレポーター、または積極的に新しいビジネスを求めている弁護士)。

The primary information that interceptions of mapping requests and responses will reveal are a location, a URI identifying a PSAP, the emergency service identifier, and the addresses of the mapping client and server. The location information can be directly useful to an attacker if the attacker has high assurance that the observed query is related to an emergency involving the target. The type of emergency (fire, police, or ambulance) might also be revealed by the emergency service identifier in the mapping query. The other pieces of information may provide the basis for further attacks on emergency call routing, but because of the time factor, are unlikely to be applicable to the routing of the current call. However, if the mapping client is the emergency caller's device, the attacker may gain information that allows for interference with the call after it has been set up or for interception of the media stream between the caller and the PSAP.

マッピングリクエストと応答の傍受が明らかになる主な情報は、場所、PSAPを識別するURI、緊急サービス識別子、およびマッピングクライアントとサーバーのアドレスです。攻撃者が観測されたクエリがターゲットに関連する緊急事態に関連していることを攻撃者が高い保証を持っている場合、位置情報は攻撃者にとって直接役立ちます。緊急事態の種類(火災、警察、または救急車)も、マッピングクエリの緊急サービス識別子によって明らかにされる場合があります。他の情報は、緊急通話ルーティングに対するさらなる攻撃の基礎を提供する場合がありますが、時間要因のため、現在の呼び出しのルーティングに適用される可能性は低いです。ただし、マッピングクライアントが緊急発信者のデバイスである場合、攻撃者は、発信者とPSAPの間のメディアストリームのセットアップ後、またはメディアストリームの傍受を可能にする情報を取得する場合があります。

6. Security Requirements Relating to Emergency Marking and Mapping
6. 緊急マーキングとマッピングに関するセキュリティ要件

This section describes the security requirements that must be fulfilled to prevent or reduce the effectiveness of the attacks described in Section 5. The requirements are presented in the same order as the attacks.

このセクションでは、セクション5で説明されている攻撃の有効性を防止または低下させるために満たされなければならないセキュリティ要件について説明します。要件は、攻撃と同じ順序で提示されます。

From Section 5.1:

セクション5.1から:

Attack A1: fraudulent calls.

攻撃A1:不正な呼び出し。

Requirement R1: For calls that meet conditions a) to c) of Section 5.1, the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP.

要件R1:条件を満たす呼び出しa)c)セクション5.1の場合、サービスプロバイダーのコールルーティングエンティティは、通話信号で提示された宛先アドレス(例:SIPリクエスト-URI)がPSAPのものであることを確認する必要があります。

Attack A2: Use of emergency identifier to probe in order to identify emergency call routing entities for attack by other means.

攻撃A2:他の手段による攻撃のための緊急コールルーティングエンティティを識別するために、緊急識別子をプローブに使用します。

Requirement: None identified, beyond the ordinary operational requirement to defend emergency call routing entities by means such as firewalls and, where possible, authentication and authorization.

要件:緊急コールルーティングエンティティをファイアウォールや可能であれば認証と承認などの手段で防御するための通常の運用上の要件を超えて、特定されていないものはありません。

From Section 5.2.1:

セクション5.2.1から:

Attack A3: Flooding attack on the mapping client, mapping server, or a third entity.

攻撃A3:マッピングクライアント、マッピングサーバー、または3番目のエンティティへのフラッディング攻撃。

Requirement R2: The mapping protocol MUST NOT create new opportunities for flooding attacks, including amplification attacks.

要件R2:マッピングプロトコルは、増幅攻撃を含む攻撃攻撃の新たな機会を生み出してはなりません。

Attack A4: Insertion of interfering messages.

攻撃A4:干渉メッセージの挿入。

Requirement R3: The protocol MUST permit the mapping client to verify that the response it receives is responding to the query it sent out.

要件R3:プロトコルは、マッピングクライアントが受信する応答が送信されたクエリに応答していることを確認することを許可する必要があります。

Attack A5: Man-in-the-middle modification of messages.

攻撃A5:メッセージの中間の修正。

Requirement R4: The mapping protocol MUST provide integrity protection of requests and responses.

要件R4:マッピングプロトコルは、リクエストと応答の整合性保護を提供する必要があります。

Requirement R5: The mapping protocol or the system within which the protocol is implemented MUST permit the mapping client to authenticate the source of mapping responses.

要件R5:マッピングプロトコルまたはプロトコルが実装されているシステムは、マッピングクライアントがマッピング応答のソースを認証できるようにする必要があります。

Attack A6: Impersonation of the mapping server.

攻撃A6:マッピングサーバーのなりすまし。

Requirement R6: The security considerations for any discussion of mapping server discovery MUST address measures to prevent impersonation of the mapping server.

要件R6:マッピングサーバーの発見に関する議論のセキュリティ上の考慮事項は、マッピングサーバーのなりすましを防ぐための措置に対処する必要があります。

Requirement R5 also follows from this attack.

要件R5もこの攻撃から続きます。

Attack A7: Corruption of the mapping database.

攻撃A7:マッピングデータベースの破損。

Requirement R7: The security considerations for the mapping protocol MUST address measures to prevent database corruption by an attacker.

要件R7:マッピングプロトコルのセキュリティ上の考慮事項は、攻撃者によるデータベースの破損を防ぐための措置に対処する必要があります。

Requirement R8: The protocol SHOULD include information in the response that allows subsequent correlation of that response with internal logs that may be kept on the mapping server, to allow debugging of mis-directed calls.

要件R8:プロトコルには、マッピングサーバーに保持される可能性のある内部ログとその応答の後続の相関を可能にする応答に情報を含める必要があります。

From Section 5.2.2: No new requirements.

セクション5.2.2から:新しい要件はありません。

From Section 5.2.3:

セクション5.2.3から:

Attack A8: Snooping of location and other information.

攻撃A8:場所やその他の情報のスヌーピング。

Requirement R9: The protocol and the system within which it is implemented MUST maintain confidentiality of the request and response.

要件R9:プロトコルとそれが実装されているシステムは、要求と応答の機密性を維持する必要があります。

7. Security Considerations
7. セキュリティに関する考慮事項

This document addresses security threats and security requirements. Therefore, security is considered throughout this document.

このドキュメントは、セキュリティの脅威とセキュリティ要件に対応しています。したがって、このドキュメント全体でセキュリティが考慮されます。

8. Acknowledgements
8. 謝辞

The writing of this document has been a task made difficult by the temptation to consider the security concerns of the entire personal emergency calling system, not just the specific pieces of work within the scope of the ECRIT Working Group. Hannes Tschofenig performed the initial security analysis for ECRIT, but it has been shaped since then by the comments and judgement of the ECRIT WG at large. At an earlier stage in the evolution of this document, Stephen Kent of the Security Directorate was asked to review it and provided extensive comments, which led to a complete rewriting of it. Brian Rosen, Roger Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran Aquil, and Ron Watro have also provided detailed reviews of this document at various stages. The authors thank them.

この文書の執筆は、ECRITワーキンググループの範囲内での特定の作業だけでなく、個人的な緊急通話システム全体のセキュリティ上の懸念を考慮する誘惑によって困難にされたタスクでした。Hannes TschofenigはECRITの最初のセキュリティ分析を実行しましたが、それ以来、ECRIT WGのコメントと判断によって形作られています。この文書の進化の初期段階で、セキュリティ局のスティーブンケントはそれをレビューし、広範なコメントを提供するように求められ、それが完全に書き直しました。ブライアン・ローゼン、ロジャー・マーシャル、アンドリュー・ニュートン、そして最近では、スペンサー・ドーキンス、カムラン・アクイル、ロン・ワトロも、さまざまな段階でこの文書の詳細なレビューを提供しています。著者は彼らに感謝します。

We would like to thank Donald Eastlake for his review on behalf of the Security Area Directorate and Christian Vogt for his review as part of the General Area Review Team.

セキュリティエリア局長とクリスチャンVOGTを代表して、一般的なエリアレビューチームの一員としてのレビューについて、ドナルドイーストレイクにレビューしてくれたことに感謝します。

Finally, we would like to thank Jari Arkko, Jon Peterson, and Russ Housley for their IETF Last Call comments.

最後に、Jari Arkko、Jon Peterson、Russ HousleyのIETF Last Callコメントに感謝します。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

9.2. Informative References
9.2. 参考引用

[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J.、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。

[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.

[RFC5012] Schulzrinne、H。and R. Marshall、ed。、「インターネットテクノロジーとの緊急コンテキスト解決の要件」、RFC 5012、2008年1月。

Authors' Addresses

著者のアドレス

Tom Taylor (editor) Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada

トム・テイラー(編集者)ノルテル1852ロレーヌアベニューオタワ、オンタリオK1H 6Z8カナダ

   EMail: tom.taylor@rogers.com
        

Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany

Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ

   EMail: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com
        

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+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu
        

Murugaraj Shanmugam Detecon International GmbH Oberkasseler str 2 Bonn, NRW 53227 Germany

Murugaraj Shanmugam Detecon International GmbH Oberkasseler Str 2 Bonn、NRW 53227ドイツ

   EMail: murugaraj.shanmugam@detecon.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(c)The IETF Trust(2008)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織(もしあれば)、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。