RFC5069 日本語訳
5069 Security Threats and Requirements for Emergency Call Marking andMapping. T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam. January 2008. (Format: TXT=26230 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
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
ワーキンググループのT.テイラー、エドをネットワークでつないでください。コメントのために以下を要求してください。 5069年のノーテルカテゴリ: 情報のH.Tschofenigノキアシーメンスはコロンビア大学M.Shanmugam Detecon2008年1月にH.Schulzrinneをネットワークでつなぎます。
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.
このドキュメントはそれらが非常時まで関係づけられるのを示す合図メッセージのマーク、およびマッピング位置のプロセスに関連している軍事的脅威をPublic Safety Answering Points(PSAPs)を示すUniversal Resource Identifiers(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.
特定された脅威に基づいて、このドキュメントは非常時で著しい呼び出しについてマッピングプロトコルと取り扱いのための1セットのセキュリティ要件を確立します。
Taylor, et al. Informational [Page 1] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [1ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 マーク、マッピング、および緊急通報ルート設定は.33.1を処理します。 マーク. . . . . . . . . . . . . . . . . . . . . . . 3 3.2に電話をしてください。 .4 4を写像します。 攻撃者. . . . . . . . . . . . . . . . . . . 4 5の目的。 可能性は.55.1を攻撃します。 非常時の識別子. . . . . . . . 5 5.2にかかわる攻撃。 マッピング処理. . . . . . . 5 5.2.1をに対して攻撃するか、または使用します。 危機対応システム. . . . 6 5.2.2に対する攻撃。 特定の個人が援助. . . . . . . . . . . . . . . . . . . . 7 5.2.3を受け取るのを防ぐ攻撃。 非常時. . . . 7 6頃に情報を得る攻撃。 非常時のマークとマッピング. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7に関連するセキュリティ要件。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 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)を使用することで緊急サービス(救急車や、消防署や、警察などの)のための助けを呼び出すことができます。 そのような呼び出しの取り扱いにおける主要因はシステムが訪問者位置を決定して、その位置に基づく適切なPublic Safety Answering Point(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
Public Switched Telephone Network(PSTN)に対する攻撃は何10年間も行われています。 インターネットはさらに敵対的な環境と考えられます。 したがって、緊急サービスを提供するインフラストラクチャに対して仕掛けられるかもしれない攻撃のタイプを理解して、それらの攻撃に対抗するためにセキュリティー対策を開発するのは重要です。 これは広い話題であるかもしれませんが、現在のドキュメントはそれ自体を非常時のマークに基づくPSAP URIと攻撃への位置に関するマッピングに対する攻撃に制限します。 PSAPによる検証
Taylor, et al. Informational [Page 2] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [2ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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.
見せかけられた位置情報の用法に関連する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.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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].
[RFC5012]から用語は「受け取り人に電話をします」、「サービスを写像し」て、「クライアントを写像し」て、「非常時の訪問者」、「非常時の識別子」が「写像され」て「マッピングサーバ」、「マッピングプロトコル」、および「公安回答ポイント(PSAP)」を取ります。
The term "location information" is taken from RFC 3693 [RFC3693].
「位置情報」という用語はRFC3693[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、H.323、または独占合図プロトコルを実行するIP電話、優しいクライアントを車で送るPCまたはアナログターミナルアダプタを含んでいるか、または住宅のゲートウェイはsoftswitchによって制御されました。
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.
呼び出し合図のマークは特定の合図メッセージが緊急通報に関連していると認める合図経路に沿って実体を可能にします。 優先権処理、特別な処理、そして/または、特別なルーティングを非常時の識別子を含んでいて、合図するのに与えるかもしれません。
Taylor, et al. Informational [Page 3] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [3ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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に呼び出しを場所を見つけて、送りますが、misroutingが貴重な時間を費やすので。 [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を受け取り返します。(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 その非常時にかかわる個人に対して攻撃者の利益におよそ非常時情報にそれを獲得する攻撃を適用できます。
Taylor, et al. Informational [Page 4] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [4ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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。 着呼アドレス(例えば、SIP Request-URI)に応じて、サービスプロバイダーは呼び出しを発送します、これがPSAPのアドレスであることを確かめない(それ自体で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で説明された攻撃者目標を達成するのに使用されるかもしれないマッピング処理にかかわる攻撃のクラスについて説明します。
Taylor, et al. Informational [Page 5] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [5ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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.
直接プロトコルデザインを写像することによって、マッピングデータベースの不正を緩和できません。 不正がいったん検出されると、どの記録が腐敗しているかを決定する際にマッピングプロトコルは担当役割を持っているかもしれません。
Taylor, et al. Informational [Page 6] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [6ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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つの可能性はマッピングクライアントがマッピングサーバの代わりに攻撃の目標に質問を写像しながら発信するのにミスリードされるということです。そのような攻撃の防止は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).
このセクションは非常時頃に情報を得るのに使用される攻撃について論じます。 攻撃者は訪問者(例えば犯罪の攻撃に作用する)の位置を探しているかもしれません。 あるいはまた、攻撃者は非常時(例えば、「警察はちょうど今だれを持ち去りましたか?」)に関連する当惑させるのについて個々(非常時にかかわる訪問者か他の誰か)の情報をリンクするのに使用できた情報を求めているかもしれません。 最終的に、攻撃者は非常時から利益を得ようとすることができました、恐らくその人のサービス(例えば、取材記者、または積極的に新しいビジネスを求めている弁護士)を提供することによって。
Taylor, et al. Informational [Page 7] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [7ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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: セクション5.1のc)に条件a)を満たす呼び出しのために、サービスプロバイダーの呼び出しルーティング実体は、呼び出し合図で提示された送付先アドレス(例えば、SIP Request-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: マッピングプロトコルは増幅攻撃を含むフラッディング攻撃の新しい機会を作成してはいけません。
Taylor, et al. Informational [Page 8] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [8ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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: プロトコルSHOULDは的外れの呼び出しのデバッグを許すためにマッピングサーバに保たれるかもしれない内部のログでその応答のその後の相関関係を許容する応答に情報を含んでいます。
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.
このドキュメントは、軍事的脅威とセキュリティが要件であると扱います。 したがって、セキュリティはこのドキュメント中で考えられます。
Taylor, et al. Informational [Page 9] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [9ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
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作業部会の範囲の中で特定の仕事だけではなく、全体のパーソナル非常時の呼ぶシステムの安全上の配慮を考える誘惑で難しくされたタスクです。 ハンネスTschofenigはECRITのために初期の証券分析を実行しましたが、それ以来、ECRIT WGのコメントと判断で詳細にそれを形成してあります。 このドキュメントの発展における早期のステージでは、Security Directorateのスティーブン・ケントは、それを見直すように頼んで、大規模なコメントを前提としました。(コメントはそれの完全な書き直しに通じました)。 また、ブライアン・ローゼン、ロジャー・マーシャル、アンドリュー・ニュートン、ごく最近、スペンサー・ダウキンズ、Kamran Aquil、およびロンWatroは様々な段階でこのドキュメントの詳細なレビューを提供しました。 作者は彼らに感謝します。
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.
彼のレビューのために司令官のArea Review Teamの一部として彼のレビューについてSecurity Area Directorateとクリスチャンのフォークトを代表してドナルド・イーストレークに感謝申し上げます。
Finally, we would like to thank Jari Arkko, Jon Peterson, and Russ Housley for their IETF Last Call comments.
最終的に、彼らのIETF Last CallコメントについてヤリArkko、ジョン・ピーターソン、およびラスHousleyに感謝申し上げます。
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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] クエリャルとJ.とモリスとJ.とマリガンとD.とピーターソン、J.とJ.ポーク、「Geopriv要件」、RFC3693、2004年2月。
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5012] SchulzrinneとH.とR.マーシャル、エド、「インターネット技術との非常時の文脈解決のための要件」、RFC5012、1月2008日
Taylor, et al. Informational [Page 10] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [10ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
Authors' Addresses
作者のアドレス
Tom Taylor (editor) Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada
トム・テイラー・(エディタ)ノーテル1852ロレーヌAveオタワ、オンタリオK1H 6Z8カナダ
EMail: tom.taylor@rogers.com
メール: tom.taylor@rogers.com
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigノキアシーメンスはオットーハーン一味6ミュンヘン、バイエルン81739ドイツをネットワークでつなぎます。
EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com
メール: Hannes.Tschofenig@nsn.com ユリ: http://www.tschofenig.com
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
Phone: +1 212 939 7004 EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
以下に電話をしてください。 +1 7004年の212 939メール: 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の国際GmbH Oberkasseler str2NRW53227ボン(ドイツ)
EMail: murugaraj.shanmugam@detecon.com
メール: murugaraj.shanmugam@detecon.com
Taylor, et al. Informational [Page 11] RFC 5069 ECRIT Security Requirements January 2008
テイラー、他 [11ページ]情報のRFC5069ECRITセキュリティ要件2008年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Taylor, et al. Informational [Page 12]
テイラー、他 情報[12ページ]
一覧
スポンサーリンク
