[要約] RFC 7378は、信頼性のある位置情報の提供に関するガイドラインです。その目的は、位置情報の収集、処理、共有におけるセキュリティとプライバシーの保護を向上させることです。
Internet Engineering Task Force (IETF) H. Tschofenig
Request for Comments: 7378 Independent
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
B. Aboba, Ed.
Microsoft Corporation
December 2014
Trustworthy Location
信頼できる場所
Abstract
概要
The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.
位置情報の信頼性は、緊急通報や路傍支援などの位置ベースのアプリケーションでは非常に重要です。
This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.
このドキュメントでは、特に緊急通報の場合の位置情報の伝達に対する脅威について説明し、位置情報の信頼性とセキュリティを向上させる手法について説明します。また、位置情報の信頼性を評価するためのガイドラインも提供します。
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/rfc7378.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7378で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Emergency Services Architecture ............................5
2. Threat Models ...................................................8
2.1. Existing Work ..............................................8
2.2. Adversary Model ............................................9
2.3. Location Spoofing .........................................10
2.4. Identity Spoofing .........................................11
3. Mitigation Techniques ..........................................11
3.1. Signed Location-by-Value ..................................12
3.2. Location-by-Reference .....................................15
3.3. Proxy-Added Location ......................................18
4. Location Trust Assessment ......................................20
5. Security Considerations ........................................23
6. Privacy Considerations .........................................24
7. Informative References .........................................26
Acknowledgments ...................................................30
Authors' Addresses ................................................30
Several public and commercial services need location information to operate. This includes emergency services (such as fire, ambulance, and police) as well as commercial services such as food delivery and roadside assistance.
いくつかの公共および商業サービスが動作するには、位置情報が必要です。これには、緊急サービス（消防、救急車、警察など）だけでなく、食料の配達や道端での援助などの商業サービスも含まれます。
For circuit-switched calls from landlines, as well as for Voice over IP (VoIP) services that only support emergency service calls from stationary Devices, location provided to the Public Safety Answering Point (PSAP) is determined from a lookup using the calling telephone number. As a result, for landlines or stationary VoIP, spoofing of caller identification can result in the PSAP incorrectly determining the caller's location. Problems relating to calling party number and Caller ID assurance have been analyzed by the Secure Telephone Identity Revisited [STIR] working group as described in "Secure Telephone Identity Problem Statement and Requirements" [RFC7340]. In addition to the work underway in STIR, other mechanisms exist for validating caller identification. For example, as noted in [EENA], one mechanism for validating caller identification information (as well as the existence of an emergency) is for the PSAP to call the user back, as described in [RFC7090].
固定電話からの回線交換コール、および固定デバイスからの緊急サービスコールのみをサポートするVoice over IP（VoIP）サービスの場合、Public Safety Answering Point（PSAP）に提供される場所は、発信電話番号を使用したルックアップから決定されます。その結果、固定電話または固定VoIPの場合、発信者IDのスプーフィングにより、PSAPが発信者の場所を誤って決定する可能性があります。 「Secure Telephone Identity Problem Statement and Requirements」[RFC7340]で説明されているように、発呼者番号と発信者IDの保証に関する問題は、Secure Telephone Identity Revisited [STIR]ワーキンググループによって分析されています。 STIRで進行中の作業に加えて、発信者識別を検証するための他のメカニズムが存在します。たとえば、[EENA]で述べられているように、[RFC7090]で説明されているように、発信者識別情報（および緊急事態の存在）を検証するメカニズムの1つは、PSAPがユーザーにコールバックすることです。
Given the existing work on caller identification, this document focuses on the additional threats that are introduced by the support of IP-based emergency services in nomadic and mobile Devices, in which location may be conveyed to the PSAP within the emergency call. Ideally, a call taker at a PSAP should be able to assess, in real time, the level of trust that can be placed on the information provided within a call. This includes automated location conveyed along with the call and location information communicated by the caller, as well as identity information relating to the caller or the Device initiating the call. Where real-time assessment is not possible, it is important to be able to determine the source of the call in a post-incident investigation, so as to be able to enforce accountability.
発信者識別に関する既存の作業を踏まえて、このドキュメントでは、位置が緊急コール内のPSAPに伝達される可能性がある、遊牧およびモバイルデバイスでのIPベースの緊急サービスのサポートによって導入される追加の脅威に焦点を当てています。理想的には、PSAPの呼び出し担当者は、呼び出し内で提供される情報に与えることができる信頼のレベルをリアルタイムで評価できる必要があります。これには、通話とともに伝えられる自動化された位置情報と、発信者が通信した位置情報、および発信者または通話を開始したデバイスに関するID情報が含まれます。リアルタイムの評価が不可能な場合は、説明責任を強化できるようにするために、事故後の調査で電話の発信元を特定できることが重要です。
This document defines terminology (including the meaning of "trustworthy location") in Section 1.1, reviews existing work in Section 1.2, describes threat models in Section 2, outlines potential mitigation techniques in Section 3, covers trust assessment in Section 4, and discusses security considerations in Section 5.
このドキュメントでは、セクション1.1で用語（「信頼できる場所」の意味を含む）を定義し、セクション1.2で既存の作業をレビューし、セクション2で脅威モデルを説明し、セクション3で潜在的な軽減手法の概要を説明し、セクション4で信頼評価をカバーし、セキュリティについて説明しますセクション5の考慮事項。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
We use the definitions of "Internet Access Provider (IAP)", "Internet Service Provider (ISP)", and "Voice Service Provider (VSP)" found in "Requirements for Emergency Context Resolution with Internet Technologies" [RFC5012].
「インターネットテクノロジーによる緊急コンテキスト解決の要件」[RFC5012]にある「インターネットアクセスプロバイダー（IAP）」、「インターネットサービスプロバイダー（ISP）」、および「音声サービスプロバイダー（VSP）」の定義を使用します。
[EENA] defines a "hoax call" as follows: "A false or malicious call is when a person deliberately telephones the emergency services and tells them there is an emergency when there is not."
[EENA]は、「いたずら電話」を次のように定義しています。「偽りの電話または悪意のある電話とは、緊急サービスに故意に電話をかけ、電話がないときに緊急事態が発生したことを伝える場合です。」
The definitions of "Device", "Target", and "Location Information Server" (LIS) are taken from "An Architecture for Location and Location Privacy in Internet Applications" [RFC6280], Section 7.
「デバイス」、「ターゲット」、「位置情報サーバー」（LIS）の定義は、「インターネットアプリケーションにおける位置と位置のプライバシーのためのアーキテクチャ」[RFC6280]、セクション7から取得されます。
The term "Device" denotes the physical device, such as a mobile phone, PC, or embedded microcontroller, whose location is tracked as a proxy for the location of a Target.
「デバイス」という用語は、位置がターゲットの位置のプロキシとして追跡される、携帯電話、PC、または組み込みマイクロコントローラーなどの物理デバイスを示します。
The term "Target" denotes an individual or other entity whose location is sought in the Geopriv architecture [RFC6280]. In many cases, the Target will be the human user of a Device, or it may be an object such as a vehicle or shipping container to which a Device is attached. In some instances, the Target will be the Device itself. The Target is the entity whose privacy the architecture described in [RFC6280] seeks to protect.
「ターゲット」という用語は、その場所がGeoprivアーキテクチャ[RFC6280]で求められている個人または他のエンティティを示します。多くの場合、ターゲットはデバイスの人間のユーザー、またはデバイスが接続されている車両や輸送用コンテナなどのオブジェクトです。場合によっては、ターゲットはデバイス自体になります。ターゲットは、[RFC6280]で説明されているアーキテクチャが保護しようとしているプライバシーを持つエンティティです。
The term "Location Information Server" denotes an entity responsible for providing Devices within an access network with information about their own locations. A Location Information Server uses knowledge of the access network and its physical topology to generate and distribute location information to Devices.
「位置情報サーバー」という用語は、アクセスネットワーク内のデバイスに自身の位置に関する情報を提供する責任があるエンティティを示します。ロケーション情報サーバーは、アクセスネットワークとその物理トポロジの知識を使用して、ロケーション情報を生成し、デバイスに配信します。
The term "location determination method" refers to the mechanism used to determine the location of a Target. This may be something employed by a LIS or by the Target itself. It specifically does not refer to the location configuration protocol (LCP) used to deliver location information to either the Target or the Recipient. This term is reused from "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations" [RFC5491].
「位置決定方法」という用語は、ターゲットの位置を決定するために使用されるメカニズムを指します。これは、LISまたはターゲット自体によって採用されたものである可能性があります。特に、ターゲットまたは受信者にロケーション情報を配信するために使用されるロケーション構成プロトコル（LCP）については言及していません。この用語は、「GEOPRIVプレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）の使用法の明確化、考慮事項、および推奨事項」[RFC5491]から再利用されています。
The term "source" is used to refer to the LIS, node, or Device from which a Recipient (Target or third party) obtains location information.
「ソース」という用語は、受信者（ターゲットまたはサードパーティ）が位置情報を取得するLIS、ノード、またはデバイスを指すために使用されます。
Additionally, the terms "location-by-value" (LbyV), "location-by-reference" (LbyR), "Location Configuration Protocol", "Location Dereference Protocol", and "Location Uniform Resource Identifier" (URI) are reused from "Requirements for a Location-by-Reference Mechanism" [RFC5808].
さらに、「location-by-value」（LbyV）、「location-by-reference」（LbyR）、「Location Configuration Protocol」、「Location Dereference Protocol」、および「Location Uniform Resource Identifier」（URI）という用語が再利用されています「参照による位置指定メカニズムの要件」[RFC5808]から。
"Trustworthy Location" is defined as location information that can be attributed to a trusted source, has been protected against modification in transmit, and has been assessed as trustworthy.
「信頼できる場所」とは、信頼できるソースに起因する可能性のある場所情報として定義され、送信中の変更から保護され、信頼できると評価されています。
"Location Trust Assessment" refers to the process by which the reliability of location information can be assessed. This topic is discussed in Section 4.
「位置信頼評価」とは、位置情報の信頼性を評価するプロセスを指します。このトピックについては、セクション4で説明します。
"Identity Spoofing" occurs when the attacker forges or obscures their identity so as to prevent themselves from being identified as the source of the attack. One class of identity spoofing attack involves the forging of call origin identification.
「IDスプーフィング」は、攻撃者がIDを偽造または不明瞭にして、攻撃元として識別されないようにするときに発生します。 IDスプーフィング攻撃の1つのクラスには、発信元IDの偽造が含まれます。
The following additional terms apply to location spoofing (Section 2.3):
ロケーションのなりすましには、次の追加条件が適用されます（セクション2.3）。
With "Place Shifting", attackers construct a Presence Information Data Format Location Object (PIDF-LO) for a location other than where they are currently located. In some cases, place shifting can be limited in range (e.g., within the coverage area of a particular cell tower).
攻撃者は、「Place Shifting」を使用して、現在の場所以外の場所に存在情報データ形式の場所オブジェクト（PIDF-LO）を作成します。場合によっては、場所の移動が範囲内で制限されることがあります（たとえば、特定のセルタワーのカバレッジエリア内）。
"Time Shifting" occurs when the attacker uses or reuses location information that was valid in the past but is no longer valid because the attacker has moved.
「タイムシフティング」は、攻撃者が過去に有効であったが、攻撃者が移動したために有効ではなくなった位置情報を使用または再利用する場合に発生します。
"Location Theft" occurs when the attacker captures a Target's location information (possibly including a signature) and presents it as their own. Location theft can occur in a single instance or may be continuous (e.g., where the attacker has gained control over the victim's Device). Location theft may also be combined with time shifting to present someone else's location information after the original Target has moved.
「ロケーション盗難」は、攻撃者がターゲットのロケーション情報（場合によっては署名を含む）をキャプチャし、それを自分のものとして提示したときに発生します。場所の盗難は、単一のインスタンスで発生する場合と、継続的な場合があります（たとえば、攻撃者が被害者のデバイスを制御した場合）。場所の盗難は、時間シフトと組み合わせて、元のターゲットが移動した後、他の誰かの場所情報を提示することもできます。
This section describes how location is utilized in the Internet Emergency Services Architecture, as well as the existing work on the problem of hoax calls.
このセクションでは、インターネット緊急サービスアーキテクチャで位置情報がどのように利用されるか、およびいたずら電話の問題に関する既存の作業について説明します。
The Internet architecture for emergency calling is described in "Framework for Emergency Calling Using Internet Multimedia" [RFC6443]. Best practices for utilizing the architecture to make emergency calls are described in "Best Current Practice for Communications Services in Support of Emergency Calling" [RFC6881].
緊急通話のインターネットアーキテクチャについては、「インターネットマルチメディアを使用した緊急通話のフレームワーク」[RFC6443]で説明されています。アーキテクチャを利用して緊急通話を行うためのベストプラクティスは、「緊急通話をサポートする通信サービスのベストプラクティス」[RFC6881]で説明されています。
As noted in "An Architecture for Location and Location Privacy in Internet Applications" [RFC6280], Section 6.3:
「インターネットアプリケーションにおけるロケーションとロケーションプライバシーのアーキテクチャ」[RFC6280]のセクション6.3に記載されているとおり：
there are three critical steps in the placement of an emergency call, each involving location information:
緊急通報の発信には3つの重要なステップがあり、それぞれに位置情報が含まれます。
1. Determine the location of the caller.
1. 発信者の場所を特定します。
2. Determine the proper Public Safety Answering Point (PSAP) for the caller's location.
2. 発信者の場所に適切な公共安全応答ポイント（PSAP）を決定します。
3. Send a SIP INVITE message, including the caller's location, to the PSAP.
3. 発信者の場所を含むSIP INVITEメッセージをPSAPに送信します。
The conveyance of location information within the Session Initiation Protocol (SIP) is described in "Location Conveyance for the Session Initiation Protocol" [RFC6442]. Conveyance of location-by-value (LbyV) as well as conveyance of location-by-reference (LbyR) are supported. Section 7 of [RFC6442] ("Security Considerations") discusses privacy, authentication, and integrity concerns relating to conveyed location. This includes discussion of transmission-layer security for confidentiality and integrity protection of SIP, as well as (undeployed) end-to-end security mechanisms for protection of location information (e.g., S/MIME). Regardless of whether transmission-layer security is utilized, location information may be available for inspection by an intermediary that -- if it decides that the location value is unacceptable or insufficiently accurate -- may send an error indication or replace the location, as described in [RFC6442], Section 3.4.
セッション開始プロトコル（SIP）内の位置情報の伝達は、「セッション開始プロトコルの位置伝達」[RFC6442]で説明されています。位置による値の伝達（LbyV）と参照による位置の伝達（LbyR）がサポートされています。 [RFC6442]のセクション7（「セキュリティに関する考慮事項」）では、伝えられる場所に関するプライバシー、認証、整合性の問題について説明しています。これには、SIPの機密性と整合性を保護するための伝送層セキュリティ、および位置情報を保護するための（展開されていない）エンドツーエンドのセキュリティメカニズム（S / MIMEなど）の説明が含まれます。伝送層のセキュリティが利用されているかどうかに関係なく、ロケーション情報は、ロケーションの値が許容できないか不十分であると判断した場合に、仲介者による検査に利用できる場合があります。 [RFC6442]、セクション3.4。
Although the infrastructure for location-based routing described in [RFC6443] was developed for use in emergency services, [RFC6442] supports conveyance of location within non-emergency calls as well as emergency calls. Section 1 of "Implications of 'retransmission-allowed' for SIP Location Conveyance" [RFC5606] describes the overall architecture, as well as non-emergency usage scenarios (note: the [LOC-CONVEY] citation in the quote below refers to the document later published as [RFC6442]):
[RFC6443]で説明されている位置ベースのルーティングのインフラストラクチャは、緊急サービスで使用するために開発されましたが、[RFC6442]は、非緊急通話および緊急通話内での位置の伝達をサポートします。 「SIPロケーション伝達の「再送信許可」の影響」[RFC5606]のセクション1は、アーキテクチャ全体、および緊急ではない使用シナリオについて説明しています（注：以下の引用の[LOC-CONVEY]引用は、ドキュメントを参照しています）後で[RFC6442]として公開）：
The Presence Information Data Format for Location Objects (PIDF-LO [RFC4119]) carries both location information (LI) and policy information set by the Rule Maker, as is stipulated in [RFC3693]. The policy carried along with LI allows the Rule Maker to restrict, among other things, the duration for which LI will be retained by recipients and the redistribution of LI by recipients.
[RFC3693]で規定されているように、ロケーションオブジェクトのプレゼンス情報データフォーマット（PIDF-LO [RFC4119]）には、ルールメーカーによって設定されたロケーション情報（LI）とポリシー情報の両方が含まれています。 LIとともに実行されるポリシーにより、ルールメーカーは、とりわけ、LIが受信者によって保持される期間と受信者によるLIの再配布を制限できます。
The Session Initiation Protocol [RFC3261] is one proposed Using Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in [LOC-CONVEY]. The common motivation for providing LI in SIP is to allow location to be considered in routing the SIP message. One example use case would be emergency services, in which the location will be used by dispatchers to direct the response. Another use case might be providing location to be used by services associated with the SIP session; a location associated with a call to a taxi service, for example, might be used to route to a local franchisee of a national service and also to route the taxi to pick up the caller.
セッション開始プロトコル[RFC3261]は、PIDF-LOの使用プロトコルとして提案されたものの1つです。 SIP内のPIDF-LOの伝達は、[LOC-CONVEY]で指定されます。 SIPでLIを提供する一般的な動機は、SIPメッセージのルーティングで場所を考慮できるようにすることです。使用例の1つは緊急サービスであり、その場所はディスパッチャが応答を指示するために使用されます。別の使用例は、SIPセッションに関連付けられたサービスが使用する場所を提供することです。たとえば、タクシーサービスへの呼び出しに関連付けられた場所は、全国サービスの地元のフランチャイズにルーティングするため、およびタクシーを呼び出して呼び出し元をピックアップするために使用することもできます。
Hoax calls have been a problem for emergency services dating back to the time of street corner call boxes. As the European Emergency Number Association (EENA) has noted [EENA]:
いたずら電話は、街角の電話ボックスの時代にさかのぼる緊急サービスにとって問題となっています。欧州緊急電話番号協会（EENA）が指摘したように[EENA]：
False emergency calls divert emergency services away from people who may be in life-threatening situations and who need urgent help. This can mean the difference between life and death for someone in trouble.
誤った緊急通報は、生命にかかわる状況にある可能性があり、緊急の支援を必要とする人々から緊急サービスをそらす。これは、困っている人の生と死の違いを意味します。
EENA [EENA] has attempted to define terminology and describe best current practices for dealing with false emergency calls. Reducing the number of hoax calls represents a challenge, since emergency services authorities in most countries are required to answer every call (whenever possible). Where the caller cannot be identified, the ability to prosecute is limited.
EENA [EENA]は、用語を定義し、誤った緊急通報に対処するための現在のベストプラクティスについて説明しようとしました。デマコールの数を減らすことは、ほとんどの国の緊急サービス当局がすべてのコールに（可能な限り）応答する必要があるため、困難を伴います。発信者を特定できない場合、起訴する能力は制限されます。
A particularly dangerous form of hoax call is "swatting" -- a hoax emergency call that draws a response from law enforcement prepared for a violent confrontation (e.g., a fake hostage situation that results in the dispatching of a "Special Weapons And Tactics" (SWAT) team). In 2008, the Federal Bureau of Investigation (FBI) issued a warning [Swatting] about an increase in the frequency and sophistication of these attacks.
デマコールの特に危険な形式は「たたく」です。これは、暴力的な対立（たとえば、「特殊兵器と戦術」の派遣につながる偽の人質の状況）に備えて法執行機関からの応答を引き出すデマ緊急コールです。スワットチーム）。 2008年、連邦捜査局（FBI）は、これらの攻撃の頻度と巧妙さの増加について警告[スワッティング]を発行しました。
Many documented cases of "swatting" (also sometimes referred to as "SWATing") involve not only the faking of an emergency but also falsification or obfuscation of identity [Swatting] [SWATing]. There are a number of techniques by which hoax callers attempt to avoid identification, and in general, the ability to identify the caller appears to influence the incidence of hoax calls.
文書化された「たたき」（「SWATing」とも呼ばれることもある）の多くの事例には、緊急事態の偽装だけでなく、身元の偽装または難読化も含まれます[Swatting] [SWATing]。デマ電話の発信者が識別を回避しようとするいくつかの手法があり、一般に、発信者を識別する機能はデマ電話の発生率に影響を与えるように見えます。
Where a Voice Service Provider allows the caller to configure its outbound caller identification without checking it against the authenticated identity, forging caller identification is trivial. Similarly, where an attacker can gain entry to a Private Branch Exchange (PBX), they can then subsequently use that access to launch a denial-of-service attack against the PSAP or make fraudulent emergency calls. Where emergency calls have been allowed from handsets lacking a subscriber identification module (SIM) card, so-called non-service initialized (NSI) handsets, or where ownership of the SIM card cannot be determined, the frequency of hoax calls has often been unacceptably high [TASMANIA] [UK] [SA].
音声サービスプロバイダーが発信者が認証されたIDと照合せずに発信者の発信者IDを構成できる場合、発信者IDを偽造することは簡単です。同様に、攻撃者が構内交換機（PBX）に侵入できる場合、その後、そのアクセスを使用して、PSAPに対してサービス拒否攻撃を仕掛けたり、不正な緊急電話をかけたりすることができます。加入者識別モジュール（SIM）カードのない受話器、いわゆる非サービス初期化（NSI）受話器からの緊急通話が許可されている場合、またはSIMカードの所有権を特定できない場合、デマコールの頻度が許容できないことが多い高い[タスマニア] [イギリス] [サ]
However, there are few documented cases of hoax calls that have arisen from conveyance of untrustworthy location information within an emergency call, which is the focus of this document.
ただし、このドキュメントの焦点である緊急コール内の信頼できない位置情報の伝達から生じたデマコールの記録されたケースはほとんどありません。
This section reviews existing analyses of the security of emergency services, threats to geographic location privacy, threats relating to spoofing of caller identification, and threats related to modification of location information in transit. In addition, the threat model applying to this work is described.
このセクションでは、緊急サービスのセキュリティ、地理的位置のプライバシーに対する脅威、発信者IDのなりすましに関する脅威、および送信中の位置情報の変更に関する脅威に関する既存の分析をレビューします。さらに、この作業に適用される脅威モデルについて説明します。
"An Architecture for Location and Location Privacy in Internet Applications" [RFC6280] describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services.
「インターネットアプリケーションでのロケーションとロケーションプライバシーのアーキテクチャ」[RFC6280]は、インターネットでのプライバシーを保護するロケーションベースのサービスのアーキテクチャについて説明し、これらのサービスで使用されるデータ形式とプロトコルの承認、セキュリティ、プライバシー要件に焦点を当てています。
In Section 5 of [RFC6280] ("An Architecture for Location and Location Privacy in Internet Applications"), mechanisms for ensuring the security of the location distribution chain are discussed; these include mechanisms for hop-by-hop confidentiality and integrity protection as well as end-to-end assurance.
[RFC6280]のセクション5（「インターネットアプリケーションにおける場所と場所のプライバシーのアーキテクチャ」）では、場所の配信チェーンのセキュリティを確保するためのメカニズムについて説明しています。これらには、ホップバイホップの機密性と整合性保護、およびエンドツーエンドの保証のためのメカニズムが含まれます。
"Geopriv Requirements" [RFC3693] focuses on the authorization, security, and privacy requirements of location-dependent services, including emergency services. Section 8 of [RFC3693] includes discussion of emergency services authentication (Section 8.3), and issues relating to identity and anonymity (Section 8.4).
「Geopriv要件」[RFC3693]は、緊急サービスを含む、場所に依存するサービスの承認、セキュリティ、およびプライバシー要件に焦点を当てています。 [RFC3693]のセクション8には、緊急サービスの認証（セクション8.3）、およびIDと匿名性に関する問題（セクション8.4）が含まれています。
"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats against geographic location privacy, including protocol threats, threats resulting from the storage of geographic location data, and threats posed by the abuse of information.
「Geoprivプロトコルの脅威分析」[RFC3694]は、プロトコルの脅威、地理的位置データの保存に起因する脅威、情報の悪用による脅威など、地理的位置のプライバシーに対する脅威について説明しています。
"Security Threats and Requirements for Emergency Call Marking and Mapping" [RFC5069] reviews security threats associated with the marking of signaling messages and the process of mapping locations to Universal Resource Identifiers (URIs) that point to PSAPs. RFC 5069 describes attacks on the emergency services system, such as attempting to deny system services to all users in a given area, to gain fraudulent use of services and to divert emergency calls to non-emergency sites. In addition, it describes attacks against individuals, including attempts to prevent an individual from receiving aid, or to gain information about an emergency, as well as attacks on emergency services infrastructure elements, such as mapping discovery and mapping servers.
「緊急コールのマーキングとマッピングのセキュリティの脅威と要件」[RFC5069]では、シグナリングメッセージのマーキングと、場所をPSAPを指すUniversal Resource Identifier（URI）にマッピングするプロセスに関連するセキュリティの脅威について説明しています。 RFC 5069は、特定のエリア内のすべてのユーザーに対してシステムサービスを拒否し、サービスを不正に利用し、緊急通話を非緊急サイトに転送するなど、緊急サービスシステムへの攻撃について説明しています。さらに、個人に対する援助の受け取りを防いだり、緊急事態に関する情報を入手したりする試みや、マッピング検出サーバーやマッピングサーバーなどの緊急サービスインフラストラクチャ要素に対する攻撃など、個人に対する攻撃についても説明します。
"Secure Telephone Identity Threat Model" [RFC7375] analyzes threats relating to impersonation and obscuring of calling party numbers, reviewing the capabilities available to attackers, and the scenarios in which attacks are launched.
「Secure Telephone Identity Threat Model」[RFC7375]は、発信者番号のなりすましや不明瞭化に関連する脅威を分析し、攻撃者が利用できる機能と、攻撃が開始されるシナリオを確認します。
To provide a structured analysis, we distinguish between three adversary models:
構造化分析を提供するために、3つの敵対モデルを区別します。
External adversary model: The end host, e.g., an emergency caller whose location is going to be communicated, is honest, and the adversary may be located between the end host and the location server or between the end host and the PSAP. None of the emergency service infrastructure elements act maliciously.
外部の敵対モデル：エンドホスト、たとえば、位置が通知される緊急発信者は正直であり、敵対者はエンドホストとロケーションサーバーの間、またはエンドホストとPSAPの間に配置される可能性があります。緊急サービスのインフラストラクチャ要素が悪意を持って動作することはありません。
Malicious infrastructure adversary model: The emergency call routing elements, such as the Location Information Server (LIS), the Location-to-Service Translation (LoST) infrastructure (which is used for mapping locations to PSAP addresses), or call routing elements, may act maliciously.
悪意のあるインフラストラクチャの敵対モデル：ロケーションインフォメーションサーバー（LIS）、ロケーションからサービスへの変換（LoST）インフラストラクチャ（ロケーションをPSAPアドレスにマッピングするために使用される）、コールルーティング要素などの緊急コールルーティング要素は、悪意を持って行動する。
Malicious end host adversary model: The end host itself acts maliciously, whether the owner is aware of this or the end host is acting under the control of a third party.
悪意のあるエンドホストの敵対モデル：所有者がこれを認識しているか、エンドホストが第三者の制御下で動作しているかに関係なく、エンドホスト自体が悪意を持って動作します。
Since previous work describes attacks against infrastructure elements (e.g., location servers, call route servers, mapping servers) or the emergency services IP network, as well as threats from attackers attempting to snoop location in transit, this document focuses on the threats arising from end hosts providing false location information within emergency calls (the malicious end host adversary model).
前の作業では、インフラストラクチャ要素（ロケーションサーバー、コールルートサーバー、マッピングサーバーなど）または緊急サービスIPネットワークに対する攻撃、および移動中に場所をスヌープしようとする攻撃者からの脅威について説明しているため、このドキュメントでは、エンドから発生する脅威に焦点を当てますホストは緊急コール内で誤った位置情報を提供します（悪意のあるエンドホストの敵対モデル）。
Since the focus is on malicious hosts, we do not cover threats that may arise from attacks on infrastructure that hosts depend on to obtain location. For example, end hosts may obtain location from civilian GPS, which is vulnerable to spoofing [GPSCounter], or from third-party Location Service Providers (LSPs) that may be vulnerable to attack or may not provide location accuracy suitable for emergency purposes.
悪意のあるホストに焦点を当てているため、ホストが場所を取得するために依存するインフラストラクチャへの攻撃から発生する可能性がある脅威は対象外です。たとえば、エンドホストは、スプーフィング[GPSCounter]に対して脆弱な民間のGPSから、または攻撃に対して脆弱である可能性がある、または緊急目的に適した位置精度を提供できないサードパーティのロケーションサービスプロバイダー（LSP）から位置を取得する場合があります。
Also, we do not cover threats arising from inadequate location infrastructure. For example, the LIS or end host could base its location determination on a stale wiremap or an inaccurate access point location database, leading to an inaccurate location estimate. Similarly, a Voice Service Provider (VSP) (and, indirectly, a LIS) could utilize the wrong identity (such as an IP address) for location lookup, thereby providing the end host with misleading location information.
また、不十分なロケーションインフラストラクチャから生じる脅威についても説明しません。たとえば、LISまたはエンドホストは、古くなったワイヤマップまたは不正確なアクセスポイントのロケーションデータベースに基づいてロケーションを決定し、不正確なロケーション推定につながる可能性があります。同様に、音声サービスプロバイダー（VSP）（および間接的にLIS）は、ロケーションルックアップに誤ったID（IPアドレスなど）を利用し、エンドホストに誤解を招くロケーション情報を提供する可能性があります。
Where location is attached to the emergency call by an end host, the end host can fabricate a PIDF-LO and convey it within an emergency call. The following represent examples of location spoofing:
ロケーションがエンドホストによって緊急コールに接続されている場合、エンドホストはPIDF-LOを作成し、それを緊急コール内で伝達できます。以下は、ロケーションのなりすましの例を示しています。
Place shifting: Mallory, the adversary, pretends to be at an arbitrary location.
場所の移動：敵対者のマロリーは、任意の場所にいるふりをします。
Time shifting: Mallory pretends to be at a location where she was a while ago.
タイムシフト：マロリーは、彼女が少し前の場所にいたふりをします。
Location theft: Mallory observes or obtains Alice's location and replays it as her own.
場所の盗難：マロリーはアリスの場所を監視または取得し、自分の場所として再生します。
While this document does not focus on the problems created by determination of location based on spoofed caller identification, the ability to ascertain identity is important, since the threat of punishment reduces hoax calls. As an example, calls from pay phones are subject to greater scrutiny by the call taker.
このドキュメントでは、発信者のなりすましに基づいて位置を特定することによって生じる問題に焦点を当てていませんが、罰の脅威によりデマコールが減少するため、身元を確認する機能が重要です。例として、公衆電話からの通話は、通話担当者による詳細な調査の対象となります。
With calls originating on an IP network, at least two forms of identity are relevant, with the distinction created by the split between the IAP and the VSP:
IPネットワークで発信されるコールでは、少なくとも2つの形式のIDが関連しており、IAPとVSPの間の分割によって作成される区別があります。
(a) network access identity such as might be determined via authentication (e.g., using the Extensible Authentication Protocol (EAP) [RFC3748]);
（a）認証（たとえば、拡張認証プロトコル（EAP）[RFC3748]を使用して）によって決定されるようなネットワークアクセスID。
(b) caller identity, such as might be determined from authentication of the emergency caller at the VoIP application layer.
（b）VoIPアプリケーション層での緊急発信者の認証から決定されるような発信者ID。
If the adversary did not authenticate itself to the VSP, then accountability may depend on verification of the network access identity. However, the network access identity may also not have been authenticated, such as in the case where an open IEEE 802.11 Access Point is used to initiate a hoax emergency call. Although endpoint information such as the IP address or Media Access Control (MAC) address may have been logged, tying this back to the Device owner may be challenging.
攻撃者がVSPに対して自身を認証しなかった場合、説明責任はネットワークアクセスIDの検証に依存する可能性があります。ただし、デマ緊急呼び出しを開始するためにオープンIEEE 802.11アクセスポイントが使用される場合など、ネットワークアクセスIDも認証されていない可能性があります。 IPアドレスやメディアアクセス制御（MAC）アドレスなどのエンドポイント情報がログに記録されている可能性がありますが、これをデバイスの所有者に結び付けるのは困難な場合があります。
Unlike the existing telephone system, VoIP emergency calls can provide an identity that need not necessarily be coupled to a business relationship with the IAP, ISP, or VSP. However, due to the time-critical nature of emergency calls, multi-layer authentication is undesirable. Thus, in most cases, only the Device placing the call will be able to be identified. Furthermore, deploying additional credentials for emergency service purposes (such as certificates) increases costs, introduces a significant administrative overhead, and is only useful if widely deployed.
既存の電話システムとは異なり、VoIP緊急通話は、必ずしもIAP、ISP、またはVSPとのビジネス関係に結合する必要がないIDを提供できます。ただし、緊急コールのタイムクリティカルな性質により、マルチレイヤ認証は望ましくありません。したがって、ほとんどの場合、コールを発信しているデバイスのみを識別できます。さらに、緊急サービスの目的で追加の資格情報（証明書など）を展開すると、コストが増加し、大幅な管理オーバーヘッドが発生し、広範囲に展開した場合にのみ役立ちます。
The sections that follow present three mechanisms for mitigating the threats presented in Section 2:
次のセクションでは、セクション2で示した脅威を軽減するための3つのメカニズムを示します。
1. Signed location-by-value (Section 3.1), which provides for authentication and integrity protection of the PIDF-LO. There is only an expired straw-man proposal for this mechanism [Loc-Dependability]; thus, as of the time of this writing this mechanism is not suitable for deployment.
1. PIDF-LOの認証と完全性保護を提供する、値による署名付きロケーション（セクション3.1）。このメカニズム[Loc-Dependability]については期限切れのストローマンの提案しかありません。したがって、この記事の執筆時点では、このメカニズムは展開に適していません。
2. Location-by-reference (Section 3.2), which enables location to be obtained by the PSAP directly from the location server, over a confidential and integrity-protected channel, avoiding modification by the end host or an intermediary. This mechanism is specified in [RFC6753].
2. 参照によるロケーション（セクション3.2）。PSAPがロケーションサーバーから直接、機密性と完全性が保護されたチャネルを介してロケーションを取得できるようにし、エンドホストまたは仲介者による変更を回避します。このメカニズムは[RFC6753]で指定されています。
3. Proxy-added location (Section 3.3), which protects against location forgery by the end host. This mechanism is specified in [RFC6442].
3. エンドホストによるロケーション偽造から保護する、プロキシが追加されたロケーション（3.3節）。このメカニズムは[RFC6442]で指定されています。
With location signing, a location server signs the location information before it is sent to the Target. The signed location information is then sent to the Location Recipient, who verifies it.
ロケーション署名を使用すると、ロケーションサーバーは、ターゲットに送信される前にロケーション情報に署名します。署名された位置情報は、それを検証する位置受信者に送信されます。
Figure 1 shows the communication model with the Target requesting signed location in step (a); the location server returns it in step (b), and it is then conveyed to the Location Recipient, who verifies it (step (c)). For SIP, the procedures described in "Location Conveyance for the Session Initiation Protocol" [RFC6442] are applicable for location conveyance.
図1は、ステップ（a）でターゲットが署名済みの場所を要求する通信モデルを示しています。ロケーションサーバーは、ステップ（b）でそれを返し、それをロケーション受信者に伝え、ロケーション受信者はそれを確認します（ステップ（c））。 SIPの場合、「セッション開始プロトコルのロケーション伝達」[RFC6442]で説明されている手順がロケーション伝達に適用されます。
+-----------+ +-----------+
| | | Location |
| LIS | | Recipient |
| | | |
+-+-------+-+ +----+------+
^ | --^
| | --
Geopriv |Req. | --
Location |Signed |Signed -- Protocol Conveying
Configuration |Loc. |Loc. -- Location (e.g., SIP)
Protocol |(a) |(b) -- (c)
| v --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 1: Location Signing
図1：場所の署名
A straw-man proposal for location signing is provided in "Digital Signature Methods for Location Dependability" [Loc-Dependability]. Note that since [Loc-Dependability] is no longer under development, location signing cannot be considered deployable at the time of this writing.
場所の署名に関するストローマンの提案は、「場所の信頼性のためのデジタル署名方法」[Loc-Dependability]で提供されています。 [Loc-Dependability]は現在開発中ではないため、この記事の執筆時点では、場所の署名を展開可能と見なすことはできません。
In order to limit replay attacks, that proposal calls for the addition of a "validity" element to the PIDF-LO, including a "from" sub-element containing the time that location information was validated by the signer, as well as an "until" sub-element containing the last time that the signature can be considered valid.
リプレイ攻撃を制限するために、その提案では、「validity」要素をPIDF-LOに追加する必要があります。これには、位置情報が署名者によって検証された時刻を含む「from」サブ要素と「署名が有効であると見なされることができる最後の時間を含むまで」サブ要素。
One of the consequences of including an "until" element is that even a stationary Target would need to periodically obtain a fresh PIDF-LO, or incur the additional delay of querying during an emergency call.
「until」要素を含めることの結果の1つは、静止しているターゲットでも定期的に新しいPIDF-LOを取得する必要があるか、緊急呼び出し中にクエリの追加の遅延が発生することです。
Although privacy-preserving procedures may be disabled for emergency calls, by design, PIDF-LO objects limit the information available for real-time attribution. As noted in [RFC5985], Section 6.6:
プライバシー保護手順は緊急通話では無効になっている可能性がありますが、設計上、PIDF-LOオブジェクトはリアルタイムアトリビューションで利用できる情報を制限しています。 [RFC5985]のセクション6.6に記載されているとおり：
The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document.
LISは、IDが正しいことを確認でき、IDの組み込みがルールメーカーによって明示的に許可されていない限り、PIDF-LOでデバイスを識別する手段を含めてはなりません。したがって、アイデンティティを含むPIDFパラメータは省略されるか、リンクされていない仮名を含みます[RFC3693]。一意のリンクされていないプレゼンティティURIは、PIDFドキュメントの必須のプレゼンス「エンティティ」属性に対してLISによって生成される必要があります。
Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used.
"contact"や "deviceID"要素[RFC4479]などのオプションのパラメーターは使用されません。
Also, the Device referred to in the PIDF-LO may not necessarily be the same entity conveying the PIDF-LO to the PSAP. As noted in [RFC6442], Section 1:
また、PIDF-LOで参照されるデバイスは、必ずしもPIDF-LOをPSAPに伝達する同じエンティティであるとは限りません。 [RFC6442]のセクション1に記載されているとおり：
In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a Device controlled by the Target, for example, a mobile phone, but such Devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location.
このドキュメントでは、ロケーションオブジェクトを含むリクエストを送信するSIPユーザーエージェントクライアントが必ずしもターゲットであるとは想定していません。 SIP内で伝達されるターゲットの場所は、通常、ターゲットによって制御されるデバイス（携帯電話など）の場所に対応しますが、そのようなデバイスは所有者から分離できます。さらに、場合によっては、ユーザーエージェントが知らないことがあります。独自の場所。
Without the ability to tie the Target identity to the identity asserted in the SIP message, it is possible for an attacker to cut and paste a PIDF-LO obtained by a different Device or user into a SIP INVITE and send this to the PSAP. This cut-and-paste attack could succeed even when a PIDF-LO is signed or when [RFC4474] is implemented.
ターゲットIDをSIPメッセージでアサートされたIDに関連付ける機能がないと、攻撃者が別のデバイスまたはユーザーが取得したPIDF-LOをSIP INVITEにカットアンドペーストして、PSAPに送信することが可能です。このカットアンドペースト攻撃は、PIDF-LOが署名されている場合、または[RFC4474]が実装されている場合でも成功する可能性があります。
To address location-spoofing attacks, [Loc-Dependability] proposes the addition of an "identity" element that could include a SIP URI (enabling comparison against the identity asserted in the SIP headers) or an X.509v3 certificate. If the Target was authenticated by the LIS, an "authenticated" attribute is added. However, because the inclusion of an "identity" element could enable location tracking, a "hash" element is also proposed that could instead contain a hash of the content of the "identity" element. In practice, such a hash would not be much better for real-time validation than a pseudonym.
ロケーションスプーフィング攻撃に対処するために、[Loc-Dependability]は、SIP URI（SIPヘッダーでアサートされたIDとの比較を可能にする）またはX.509v3証明書を含むことができる「identity」要素の追加を提案します。ターゲットがLISによって認証された場合、「authenticated」属性が追加されます。ただし、「identity」要素を含めると位置追跡が可能になるため、代わりに「identity」要素のコンテンツのハッシュを含めることができる「hash」要素も提案されています。実際には、そのようなハッシュは、仮名よりもリアルタイムの検証にはあまり適していません。
Location signing cannot deter attacks in which valid location information is provided. For example, an attacker in control of compromised hosts could launch a denial-of-service attack on the PSAP by initiating a large number of emergency calls, each containing valid signed location information. Since the work required to verify the location signature is considerable, this could overwhelm the PSAP infrastructure.
ロケーション署名は、有効なロケーション情報が提供される攻撃を阻止できません。たとえば、侵害されたホストを制御する攻撃者は、有効な署名された位置情報を含む多数の緊急コールを開始することにより、PSAPにサービス拒否攻撃を開始する可能性があります。場所の署名を検証するために必要な作業はかなりのものなので、これはPSAPインフラストラクチャを圧倒する可能性があります。
However, while DDoS attacks are unlikely to be deterred by location signing, accurate location information would limit the subset of compromised hosts that could be used for an attack, as only hosts within the PSAP serving area would be useful in placing emergency calls.
ただし、DDoS攻撃がロケーション署名によって阻止される可能性は低いですが、緊急コールの発信に役立つのはPSAPサービングエリア内のホストのみであるため、正確なロケーション情報により、攻撃に使用される可能性のある侵害されたホストのサブセットが制限されます。
Location signing is also difficult when the host obtains location via mechanisms such as GPS, unless trusted computing approaches, with tamper-proof GPS modules, can be applied. Otherwise, an end host can pretend to have GPS, and the Recipient will need to rely on its ability to assess the level of trust that should be placed in the end host location claim.
ホストがGPSなどのメカニズムを介して位置を取得する場合、改ざん防止GPSモジュールを使用した信頼できるコンピューティングアプローチを適用できない限り、位置の署名も困難です。そうでない場合、エンドホストはGPSを装ったふりをすることができ、受信者はエンドホストロケーションのクレームに置かれるべき信頼レベルを評価する能力に依存する必要があります。
Even though location-signing mechanisms have not been standardized, [NENA-i2], Section 4.7 includes operational recommendations relating to location signing:
場所の署名メカニズムは標準化されていませんが[NENA-i2]、セクション4.7には場所の署名に関する運用上の推奨事項が含まれています。
Location configuration and conveyance requirements are described in NENA 08-752[27], but guidance is offered here on what should be considered when designing mechanisms to report location:
場所の構成と伝達の要件はNENA 08-752 [27]で説明されていますが、場所を報告するメカニズムを設計する際に考慮すべき点について、以下のガイダンスが提供されています。
1. The location object should be digitally signed.
1. ロケーションオブジェクトはデジタル署名されている必要があります。
2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certificates to LIS operators.
2. 署名者（LISオペレーター）の証明書は、VESAをルートとする必要があります。この目的のために、VPCおよびERDBオペレーターはLISオペレーターに証明書を発行する必要があります。
3. The signature should include a timestamp.
3. 署名にはタイムスタンプを含める必要があります。
4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence.
4. 可能な場合は、ロケーションオブジェクトを定期的に更新する必要があります。その結果、シグネチャ（およびタイムスタンプ）が更新されます。
5. Antispoofing mechanisms should be applied to the Location Reporting method.
5. 現在地の報告方法には、なりすまし防止メカニズムを適用する必要があります。
(Note: The term "Valid Emergency Services Authority" (VESA) refers to the root certificate authority. "VPC" stands for VoIP Positioning Center, and "ERDB" stands for the Emergency Service Zone Routing Database.)
（注：「有効な緊急サービス機関（VESA）」という用語はルート認証局を指します。「VPC」はVoIPポジショニングセンターを表し、「ERDB」は緊急サービスゾーンルーティングデータベースを表します。）
As noted above, signing of location objects implies the development of a trust hierarchy that would enable a certificate chain provided by the LIS operator to be verified by the PSAP. Rooting the trust hierarchy in the VESA can be accomplished either by having the VESA directly sign the LIS certificates or by the creation of intermediate Certificate Authorities (CAs) certified by the VESA, which will then issue certificates to the LIS. In terms of the workload imposed on the VESA, the latter approach is highly preferable. However, this raises the question of who would operate the intermediate CAs and what the expectations would be.
上記のように、ロケーションオブジェクトの署名は、LISオペレーターによって提供される証明書チェーンをPSAPで検証できるようにする信頼階層の開発を意味します。 VESAで信頼階層をルート化するには、VESAにLIS証明書に直接署名させるか、VESAによって認証された中間認証局（CA）を作成して、LISに証明書を発行します。 VESAに課されるワークロードの観点から、後者のアプローチが非常に望ましいです。ただし、これにより、中間CAを運用するのは誰であり、何が期待されるのかという疑問が生じます。
In particular, the question arises as to the requirements for LIS certificate issuance, and how they would compare to requirements for issuance of other certificates such as a Secure Socket Layer/Transport Layer Security (SSL/TLS) web certificate.
特に、LIS証明書の発行の要件、およびSecure Socket Layer / Transport Layer Security（SSL / TLS）Web証明書などの他の証明書の発行の要件とどのように比較するかという疑問が生じます。
Location-by-reference was developed so that end hosts can avoid having to periodically query the location server for up-to-date location information in a mobile environment. Additionally, if operators do not want to disclose location information to the end host without charging them, location-by-reference provides a reasonable alternative. Also, since location-by-reference enables the PSAP to directly contact the location server, it avoids potential attacks by intermediaries.
参照によるロケーションは、エンドホストがモバイル環境で定期的にロケーションサーバーに最新のロケーション情報を照会する必要がないように開発されました。さらに、オペレーターがロケーション情報をエンドホストに請求せずにエンドホストに開示したくない場合は、参照によるロケーションが妥当な代替手段となります。また、location-by-referenceを使用すると、PSAPがロケーションサーバーに直接接続できるため、仲介者による潜在的な攻撃を回避できます。
As noted in "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location reference can be obtained via HELD [RFC5985]. In addition, "Location Configuration Extensions for Policy Management" [RFC7199] extends location configuration protocols such as HELD to provide hosts with a reference to the rules that apply to a location-by-reference so that the host can view or set these rules.
「HTTP対応のロケーション配信（HELD）を使用したロケーション参照解除プロトコル」[RFC6753]に記載されているように、ロケーション参照はHELD [RFC5985]を介して取得できます。さらに、「ポリシー管理用のロケーション構成拡張」[RFC7199]は、HELDなどのロケーション構成プロトコルを拡張して、ホストがこれらのルールを表示または設定できるように、参照によるロケーションに適用されるルールへの参照をホストに提供します。
Figure 2 shows the communication model with the Target requesting a location reference in step (a); the location server returns the reference and, potentially, the policy in step (b), and it is then conveyed to the Location Recipient in step (c). The Location Recipient needs to resolve the reference with a request in step (d). Finally, location information is returned to the Location Recipient afterwards. For location conveyance in SIP, the procedures described in [RFC6442] are applicable.
図2は、ステップ（a）でターゲットが位置参照を要求している通信モデルを示しています。ロケーションサーバーは参照と、場合によってはステップ（b）でポリシーを返し、それがステップ（c）でロケーション受信者に伝達されます。ロケーション受信者は、ステップ（d）のリクエストで参照を解決する必要があります。最後に、位置情報は後でLocation Recipientに返されます。 SIPでのロケーション伝達には、[RFC6442]で説明されている手順が適用されます。
+-----------+ Geopriv +-----------+
| | Location | Location |
| LIS +<------------->+ Recipient |
| | Dereferencing | |
+-+-------+-+ Protocol (d) +----+------+
^ | --^
| | --
Geopriv |Req. |LbyR + --
Location |LbyR |Policy -- Protocol Conveying
Configuration |(a) |(b) -- Location (e.g., SIP)
Protocol | | -- (c)
| V --
+-+-------+-+ --
| Target / | --
| End Host +
| |
+-----------+
Figure 2: Location-by-Reference
図2：参照による場所
Where location-by-reference is provided, the Recipient needs to dereference the LbyR in order to obtain location. The details for the dereferencing operations vary with the type of reference, such as an HTTP, HTTPS, SIP, secure SIP (SIPS), or SIP Presence URI.
参照による場所が提供されている場合、受信者は場所を取得するためにLbyRを逆参照する必要があります。逆参照操作の詳細は、HTTP、HTTPS、SIP、セキュアSIP（SIPS）、SIPプレゼンスURIなどの参照のタイプによって異なります。
For location-by-reference, the location server needs to maintain one or several URIs for each Target, timing out these URIs after a certain amount of time. References need to expire to prevent the Recipient of such a Uniform Resource Locator (URL) from being able to permanently track a host and to offer garbage collection functionality for the location server.
ロケーションバイリファレンスの場合、ロケーションサーバーは各ターゲットに対して1つまたは複数のURIを維持し、一定の時間が経過するとこれらのURIをタイムアウトにする必要があります。このようなUniform Resource Locator（URL）の受信者がホストを永続的に追跡できず、ロケーションサーバーにガベージコレクション機能を提供できないようにするには、参照が期限切れになる必要があります。
Off-path adversaries must be prevented from obtaining the Target's location. The reference contains a randomized component that prevents third parties from guessing it. When the Location Recipient fetches up-to-date location information from the location server, it can also be assured that the location information is fresh and not replayed. However, this does not address location theft.
パス外の敵がターゲットの位置を取得できないようにする必要があります。参照には、第三者が推測できないようにするランダム化されたコンポーネントが含まれています。ロケーション受信者がロケーションサーバーから最新のロケーション情報をフェッチすると、ロケーション情報が最新で再生されないことも保証されます。ただし、これはロケーションの盗難には対応していません。
With respect to the security of the dereference operation, [RFC6753], Section 6 states:
逆参照操作のセキュリティに関して、[RFC6753]のセクション6には次のように記載されています。
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted.
セクション3で説明されているように、他のメカニズムによって機密性と整合性が提供されていない限り、ロケーションURIの逆参照にTLSを使用する必要があります。ロケーションの受信者は、3.1で説明されている手順を使用して、ロケーションURIに含まれるドメイン名を使用してホストIDを認証する必要があります。 [RFC2818]。ローカルポリシーは、認証が失敗した場合や試行できない場合にロケーション受信者が何をするかを決定します。
The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references.
所有モデルによる承認（セクション4.1）は、URIの機密性を保護するためにロケーションURIを送信するときに、TLSにさらに依存します。そのようなURIの所有は、URIが参照するPIDF-LOドキュメントの所有と同じプライバシーの考慮事項を意味します。
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI.
ロケーションURIは、許可されたロケーション受信者にのみ開示する必要があります。 GEOPRIVアーキテクチャ[RFC6280]は、URIの開示を承認するようにルールメーカーを指定します。
Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442].
ロケーションURIに添付されたポリシーは、URIを持っているすべてのユーザーが関連するロケーション情報を表示できるため、ロケーションURIの保護が必要です。セキュリティのこの側面については、[RFC6442]などのロケーション伝達プロトコルの仕様で詳しく説明しています。
For authorizing access to location-by-reference, two authorization models were developed: "Authorization by Possession" and "Authorization via Access Control Lists". With respect to "Authorization by Possession", [RFC6753], Section 4.1 notes:
参照による場所へのアクセスを承認するために、「所有による承認」と「アクセス制御リストによる承認」の2つの承認モデルが開発されました。 「所持による承認」、[RFC6753]、セクション4.1に関する注記：
In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI.
このモデルでは、ロケーションURIの所有（または知識）を使用して、ロケーション情報へのアクセスを制御します。ロケーションURIは、推測が困難になるように構築される場合があり（[RFC5808]のC8を参照）、それが開示されるエンティティのセットは制限される場合があります。これがLSで必要とする唯一の認証は、URIの所有の証拠です。 LSは、このURIを示すリクエストをすぐに承認できます。
Authorization by possession does not require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker.
所有による承認には、ルールメーカーとの直接のやり取りは必要ありません。ルールメーカーは、ロケーションURIの配布を制御できると想定されています。したがって、LISはルールメーカーからの限られたポリシー入力で動作できます。
Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers.
制限付きの開示は、この承認モデルの重要な側面です。ロケーションURIは秘密です。したがって、攻撃者がこの情報を取得できないようにすることが最も重要です。 TLS [RFC5246]やS / MIME [RFC5751]によって提供されるような暗号化は、盗聴者から情報を保護します。
...
。。。
Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue to learn new location URIs to retain access to current location information.
所有権を承認の基礎として使用するということは、いったん付与されると、承認を簡単に取り消すことができないことを意味します。ロケーションURIをキャンセルすると、正当なユーザーにも影響が及ぶことが保証されます。追加のポリシーの適用は理論的には可能ですが、技術的に不可能である可能性があります。ロケーションURIの有効期限は、ロケーションURIの使用可能時間を制限し、攻撃者が現在のロケーション情報へのアクセスを保持するために新しいロケーションURIを学習し続けることを要求します。
In situations where "Authorization by Possession" is not suitable (such as where location hiding [RFC6444] is required), the "Authorization via Access Control Lists" model may be preferred.
「所持による承認」が適さない状況（場所非表示[RFC6444]が必要な場合など）では、「アクセス制御リストによる承認」モデルが優先される場合があります。
Without the introduction of a hierarchy, it would be necessary for the PSAP to obtain credentials, such as certificates or shared symmetric keys, for all the LISs in its coverage area, to enable it to successfully dereference LbyRs. In situations with more than a few LISs per PSAP, this would present operational challenges.
階層を導入しない場合、PSAPがLbyRを正常に逆参照できるようにするには、PSAPがカバレッジエリア内のすべてのLISについて、証明書や共有対称キーなどの資格情報を取得する必要があります。 PSAPあたりのLISがいくつかある状況では、運用上の課題が生じます。
A certificate hierarchy providing PSAPs with client certificates chaining to the VESA could be used to enable the LIS to authenticate and authorize PSAPs for dereferencing. Note that unlike PIDF-LO signing (which mitigates modification of PIDF-LOs), this merely provides the PSAP with access to a (potentially unsigned) PIDF-LO, albeit over a protected TLS channel.
VESAに連鎖するクライアント証明書をPSAPに提供する証明書階層を使用して、LISがPSAPを認証し、逆参照することを許可することができます。 PIDF-LO署名（PIDF-LOの変更を軽減する）とは異なり、これは、保護されたTLSチャネルを介しても、PSAPに（署名されていない可能性がある）PIDF-LOへのアクセスを提供するだけです。
Another approach would be for the local LIS to upload location information to a location aggregation point who would in turn manage the relationships with the PSAP. This would shift the management burden from the PSAPs to the location aggregation points.
もう1つのアプローチは、ローカルLISがロケーション情報をロケーション集約ポイントにアップロードし、PSAPとの関係を管理することです。これにより、管理の負担がPSAPからロケーション集約ポイントに移ります。
Instead of relying upon the end host to provide location, is possible for a proxy that has the ability to determine the location of the end point (e.g., based on the end host IP or MAC address) to retrieve and add or override location information. This requires deployment of application-layer entities by ISPs, unlike the two other techniques. The proxies could be used for emergency or non-emergency communications, or both.
エンドホストに依存して場所を提供する代わりに、エンドポイントの場所を（たとえば、エンドホストIPまたはMACアドレスに基づいて）決定して、場所情報を取得および追加またはオーバーライドする機能を持つプロキシが可能です。これには、他の2つの手法とは異なり、ISPによるアプリケーション層エンティティの展開が必要です。プロキシは、緊急通信または非緊急通信、あるいはその両方に使用できます。
The use of proxy-added location is primarily applicable in scenarios where the end host does not provide location. As noted in [RFC6442], Section 4.1:
プロキシが追加された場所の使用は、エンドホストが場所を提供しないシナリオに主に適用されます。 [RFC6442]のセクション4.1に記載されているとおり：
A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request.
SIP仲介者は、既に場所を含んでいるSIPリクエストに場所を追加してはいけません（SHOULD NOT）。これにより、LR内で混乱が生じることがよくあります。ただし、SIP仲介者が場所を追加する場合、場所が以前にSIPリクエストに存在していなかったとしても、そのSIP仲介者は、この場所の追加について受け取った424（Bad Location Information）SIP応答の懸念に対処する責任を完全に担っています。 424応答を（上流に）渡します。 locationValueを追加するSIP仲介者は、新しいlocationValueをSIPリクエストのGeolocationヘッダーフィールド内の最後のlocationValueとして配置する必要があります。
...
。。。
A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3).
SIP仲介者が存在しない場合は、Geolocationヘッダーフィールドを追加してもかまいません。たとえば、ユーザーエージェントがGeolocationメカニズムをサポートしていないが、それらのアウトバウンドプロキシがターゲットの場所をサポートしていて、他の多くのユースケースのいずれかを知っている場合（セクション3を参照）。
As noted in [RFC6442], Section 3.3:
[RFC6442]に記載されているように、セクション3.3：
This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4).
このドキュメントでは、「あなたはそれを壊し、あなたはそれを買った」というアプローチをとり、中間エンティティによってSIPリクエストに配置された2番目の場所を扱います。そのエンティティは、そのSIPリクエスト内のすべての場所を完全に担当します（これについては、セクション4で詳しく説明します）。
While it is possible for the proxy to override location included by the end host, [RFC6442], Section 3.4 notes the operational limitations:
プロキシがエンドホスト[RFC6442]に含まれている場所を上書きすることは可能ですが、セクション3.4には運用上の制限が記載されています。
Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another.
ユーザーが提供する位置情報を上書きするには、仲介者がエンドユーザーよりも必然的に知っている配置が必要です。結局のところ、アリスはオンボードGPSを持っていて、SIP仲介者は最も近いセルタワーしか知らない可能性があります。より正確な位置情報はどれですか？現在、どのエンティティがより正確であるか、どちらが間違っているかを知る方法はありません。このドキュメントでは、どの場所が他の場所よりも正確であるかを示す方法を指定しません。
The disadvantage of this approach is the need to deploy application-layer entities, such as SIP proxies, at IAPs or associated with IAPs. This requires that a standardized VoIP profile be deployed at every end Device and at every IAP. This might impose interoperability challenges.
このアプローチの欠点は、IAPに、またはIAPに関連付けられて、SIPプロキシなどのアプリケーション層エンティティを展開する必要があることです。これには、すべてのエンドデバイスとすべてのIAPに標準化されたVoIPプロファイルを展開する必要があります。これは相互運用性の課題を課す可能性があります。
Additionally, the IAP needs to take responsibility for emergency calls, even for customers with whom they have no direct or indirect relationship. To provide identity information about the emergency caller from the VSP, it would be necessary to let the IAP and the VSP interact for authentication (see, for example, "Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). This interaction along the Authentication, Authorization, and Accounting infrastructure is often based on business relationships between the involved entities. An arbitrary IAP and VSP are unlikely to have a business relationship. If the interaction between the IAP and the VSP fails due to the lack of a business relationship, then typically a fall-back would be provided where no emergency caller identity information is made available to the PSAP and the emergency call still has to be completed.
さらに、IAPは、直接または間接的な関係を持たない顧客であっても、緊急通話の責任を負う必要があります。 VSPから緊急発信者に関するID情報を提供するには、IAPとVSPが認証のために相互作用するようにする必要があります（たとえば、「Diameterセッション開始プロトコル（SIP）アプリケーション」[RFC4740]を参照）。認証、承認、および会計インフラストラクチャに沿ったこの相互作用は、多くの場合、関係するエンティティ間のビジネス関係に基づいています。任意のIAPとVSPがビジネス関係を持つことはほとんどありません。ビジネス関係がないためにIAPとVSP間の相互作用が失敗した場合、通常、PSAPで緊急発信者ID情報を使用できず、緊急コールを完了する必要があるフォールバックが提供されます。
The ability to assess the level of trustworthiness of conveyed location information is important, since this makes it possible to understand how much value should be placed on location information as part of the decision-making process. As an example, if automated location information is understood to be highly suspect or is absent, a call taker can put more effort into verifying the authenticity of the call and obtaining location information from the caller.
意思決定プロセスの一環として位置情報にどの程度の価値を置く必要があるかを理解できるため、伝達される位置情報の信頼性のレベルを評価する機能は重要です。一例として、自動化された位置情報が非常に疑わしい、または存在しないと理解されている場合、呼び出し担当者は、呼び出しの信憑性の検証と呼び出し元からの位置情報の取得により多くの労力を費やすことができます。
Location trust assessment has value, regardless of whether the location itself is authenticated (e.g., signed location) or is obtained directly from the location server (e.g., location-by-reference) over security transport, since these mechanisms do not provide assurance of the validity or provenance of location data.
ロケーション自体が認証されているか（署名されたロケーションなど）、またはセキュリティトランスポートを介してロケーションサーバーから直接取得されているか（参照によるロケーションなど）に関係なく、ロケーション信頼評価には価値があります。これらのメカニズムは位置データの有効性または来歴。
To prevent location-theft attacks, the "entity" element of the PIDF-LO is of limited value if an unlinked pseudonym is provided in this field. However, if the LIS authenticates the Target, then the linkage between the pseudonym and the Target identity can be recovered in a post-incident investigation.
ロケーション盗難攻撃を防ぐために、リンクされていない仮名がこのフィールドに入力されている場合、PIDF-LOの「エンティティ」要素の値は制限されます。ただし、LISがターゲットを認証すると、インシデント後の調査で、仮名とターゲットID間のリンクを回復できます。
As noted in [Loc-Dependability], if the location object was signed, the Location Recipient has additional information on which to base their trust assessment, such as the validity of the signature, the identity of the Target, the identity of the LIS, whether the LIS authenticated the Target, and the identifier included in the "entity" field.
[Loc-Dependability]で説明したように、ロケーションオブジェクトが署名されている場合、ロケーション受信者は、署名の有効性、ターゲットのID、LISのIDなど、信頼評価の基礎となる追加情報を持っています。 LISがターゲットを認証したかどうか、および「エンティティ」フィールドに含まれている識別子。
Caller accountability is also an important aspect of trust assessment. Can the individual purchasing the Device or activating service be identified, or did the call originate from a non-service initialized (NSI) Device whose owner cannot be determined? Prior to the call, was the caller authenticated at the network or application layer? In the event of a hoax call, can audit logs be made available to an investigator, or can information relating to the owner of an unlinked pseudonym be provided, enabling investigators to unravel the chain of events that led to the attack?
発信者の説明責任も信頼評価の重要な側面です。デバイスを購入したり、サービスをアクティブ化したりする個人を特定できますか、または所有者を特定できない非サービス初期化（NSI）デバイスから通話を発信しましたか？通話の前に、発信者はネットワークまたはアプリケーション層で認証されましたか？デマコールが発生した場合、監査ログを調査員が利用できるようにしたり、リンクされていない仮名の所有者に関する情報を提供したりして、調査員が攻撃につながった一連のイベントを解明できるようにすることはできますか？
In practice, the source of the location data is important for location trust assessment. For example, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g., United States Phase II E-911 location accuracy) may be considered more reliable than location information provided by a third-party Location Service Provider (LSP) that disclaims use of location information for emergency purposes.
実際には、ロケーションデータのソースは、ロケーションの信頼性評価にとって重要です。たとえば、管理者が緊急の位置精度要件（たとえば、米国フェーズII E-911の位置精度）を満たす既成の履歴を持っている位置情報サーバー（LIS）によって提供される位置情報は、3番目の情報によって提供される位置情報よりも信頼性が高いと考えられます。緊急目的での位置情報の使用を否認するサードパーティのロケーションサービスプロバイダー（LSP）。
However, even where an LSP does not attempt to meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g., the tower or AP owner), and when was the last time that the location of the tower or access point was verified?
ただし、LSPが緊急ロケーションの精度要件を満たさない場合でも、ロケーション情報の信頼性を評価するのに役立つ情報を提供できる場合があります。たとえば、最も近いセルタワーまたは802.11アクセスポイント（AP）に基づいて場所が決定されましたか、それとも三角測量法が使用されましたか？セルタワーまたはAPの位置データに基づいている場合、情報は信頼できるソース（タワーまたはAPの所有者など）から取得したもので、最後にタワーまたはアクセスポイントの位置が確認されたのはいつですか。
For real-time validation, information in the signaling and media packets can be cross-checked against location information. For example, it may be possible to determine the city, state, country, or continent associated with the IP address included within SIP Via or Contact header fields, or the media source address, and compare this against the location information reported by the caller or conveyed in the PIDF-LO. However, in some situations, only entities close to the caller may be able to verify the correctness of location information.
リアルタイムの検証では、シグナリングパケットとメディアパケットの情報を位置情報と照合できます。たとえば、SIP ViaまたはContactヘッダーフィールドに含まれるIPアドレスに関連付けられている都市、州、国、大陸、またはメディアソースアドレスを特定し、これを発信者またはPIDF-LOで伝達されます。ただし、状況によっては、発信者に近いエンティティのみが位置情報の正確さを確認できる場合があります。
Real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is also challenging. To address time-shifting attacks, the "timestamp" element of the PIDF-LO, defined in [RFC3863], can be examined and compared against timestamps included within the enclosing SIP message, to determine whether the location data is sufficiently fresh. However, the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the Recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the Recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISs. As a result, Recipients need to validate the timestamp in order to determine whether it is credible.
PIDF-LOオブジェクト内に含まれるタイムスタンプのリアルタイム検証（場所が決定された時刻を反映）も困難です。タイムシフト攻撃に対処するには、[RFC3863]で定義されているPIDF-LOの「タイムスタンプ」要素を調べ、SIPメッセージに含まれるタイムスタンプと比較して、位置データが十分に新しいかどうかを判断します。ただし、タイムスタンプはLISによるアサーションを表すだけであり、信頼できる場合とそうでない場合があります。たとえば、署名されたPIDF-LOの受信者は、LISが時間同期をサポートしているかどうか、またはLISクロックを検出せずに手動でリセットできるかどうかを知らない場合があります。場所が決定された時点でタイムスタンプが有効であったとしても、PIDF-LOが提供されてから受信者に伝達されるまでに時間がかかる場合があります。位置情報自体が変更されていなくても、定期的に位置情報を更新してタイムスタンプを更新すると、LISに追加の負荷がかかります。その結果、受信者はタイムスタンプが信頼できるかどうかを判断するためにタイムスタンプを検証する必要があります。
While this document focuses on the discussion of real-time determination of suspicious emergency calls, the use of audit logs may help in enforcing accountability among emergency callers. For example, in the event of a hoax call, information relating to the owner of the unlinked pseudonym could be provided to investigators, enabling them to unravel the chain of events that led to the attack. However, while auditability is an important deterrent, it is likely to be of most benefit in situations where attacks on the emergency services system are likely to be relatively infrequent, since the resources required to pursue an investigation are likely to be considerable. However, although real-time validation based on PIDF-LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking of a pseudonym to the Device obtaining location can be accomplished during an investigation.
このドキュメントでは、不審な緊急通話のリアルタイムの決定について説明しますが、監査ログを使用すると、緊急の発信者に説明責任を強制するのに役立ちます。たとえば、デマコールが発生した場合、リンクされていない仮名の所有者に関する情報を調査員に提供して、攻撃につながった一連のイベントを解明することができます。ただし、監査可能性は重要な抑止力ですが、調査を行うために必要なリソースがかなり多いため、緊急サービスシステムへの攻撃が比較的まれである可能性が高い状況では、最も有益になる可能性があります。ただし、PIDF-LO要素に基づくリアルタイム検証は困難ですが、LIS監査ログが利用できる場合（法執行機関が召喚状を提示できる場合など）、仮名のデバイス取得場所へのリンクは、調査。
Where attacks are frequent and continuous, automated mechanisms are required. For example, it might be valuable to develop mechanisms to exchange audit trail information in a standardized format between ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish potentially fraudulent emergency calls from real emergencies. While a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) may be applied to suspicious calls to lower the risk from bot-nets, this is quite controversial for emergency services, due to the risk of delaying or rejecting valid calls.
攻撃が頻繁かつ継続的である場合、自動化されたメカニズムが必要です。たとえば、ISPとPSAP / VSPとPSAPの間で監査証跡情報を標準化された形式で交換するメカニズム、またはヒューリスティックを開発して、詐欺の可能性がある緊急コールを実際の緊急事態から区別することは価値があります。 Computers and Humans Apart（CAPTCHA）を完全に自動化したパブリックチューリングテスト（CAPTCHA）をボットネットからのリスクを減らすために適用することはできますが、有効な通話を遅らせたり拒否したりするリスクがあるため、緊急サービスではこれは非常に物議を醸しています。
Although it is important to ensure that location information cannot be faked, the mitigation techniques presented in this document are not universally applicable. For example, there will be many GPS-enabled Devices that will find it difficult to utilize any of the solutions described in Section 3. It is also unlikely that users will be willing to upload their location information for "verification" to a nearby location server located in the access network.
位置情報が偽造されないようにすることが重要ですが、このドキュメントに記載されている軽減策は、広く適用できるものではありません。たとえば、セクション3で説明されているソリューションのいずれかを利用するのが難しいと思われる多くのGPS対応デバイスがあります。また、ユーザーが「確認」のために位置情報を近くのロケーションサーバーにアップロードすることを望んでいる可能性も低いです。アクセスネットワークにあります。
This document focuses on threats that arise from conveyance of misleading location information, rather than caller identification or authentication and integrity protection of the messages in which location is conveyed. Nevertheless, these aspects are important. In some countries, regulators may not require the authenticated identity of the emergency caller (e.g., emergency calls placed from Public Switched Telephone Network (PSTN) pay phones or SIM-less cell phones). Furthermore, if identities can easily be crafted (as is the case with many VoIP offerings today), then the value of emergency caller authentication itself might be limited. As a result, attackers can forge emergency calls with a lower risk of being held accountable, which may encourage hoax calls.
このドキュメントでは、発信者の識別や、場所が伝達されるメッセージの認証および整合性保護ではなく、誤解を招く位置情報の伝達から生じる脅威に焦点を当てています。それにもかかわらず、これらの側面は重要です。一部の国では、規制当局は緊急発信者の認証済みIDを要求しない場合があります（例：公衆交換電話網（PSTN）公衆電話またはSIMなしの携帯電話からの緊急電話）。さらに、（今日の多くのVoIPサービスの場合のように）IDを簡単に作成できる場合は、緊急発信者認証自体の価値が制限される可能性があります。その結果、攻撃者は責任を問われるリスクが低い緊急電話を偽造できるため、デマコールを助長する可能性があります。
In order to provide authentication and integrity protection for the Session Initiation Protocol (SIP) messages conveying location, several security approaches are available. It is possible to ensure that modification of the identity and location in transit can be detected by the Location Recipient (e.g., the PSAP), using cryptographic mechanisms, as described in "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474]. However, compatibility with Session Border Controllers (SBCs) that modify integrity-protected headers has proven to be an issue in practice, and as a result, a revision of [RFC4474] is in progress [SIP-Identity]. In the absence of an end-to-end solution, SIP over Transport Layer Security (TLS) can be used to provide message authentication and integrity protection hop by hop.
ロケーションを伝えるセッション開始プロトコル（SIP）メッセージに認証と整合性保護を提供するために、いくつかのセキュリティアプローチが利用できます。 「セッション開始プロトコル（SIP）での認証済みアイデンティティ管理の拡張機能」で説明されているように、暗号メカニズムを使用して、ロケーション受信者（PSAPなど）が移動中のアイデンティティとロケーションの変更を確実に検出できるようにすることができます。 [RFC4474]。ただし、整合性で保護されたヘッダーを変更するセッションボーダーコントローラー（SBC）との互換性が実際に問題であることが判明しているため、[RFC4474]の改訂が進行中です[SIP-Identity]。エンドツーエンドのソリューションがない場合、SIP over Transport Layer Security（TLS）を使用して、ホップごとにメッセージ認証と整合性保護を提供できます。
PSAPs remain vulnerable to distributed denial-of-service attacks, even where the mitigation techniques described in this document are utilized. Placing a large number of emergency calls that appear to come from different locations is an example of an attack that is difficult to carry out within the legacy system but is easier to imagine within IP-based emergency services. Also, in the current system, it would be very difficult for an attacker from one country to attack the emergency services infrastructure located in another country, but this attack is possible within IP-based emergency services.
PSAPは、このドキュメントで説明されている軽減技術が利用されている場合でも、分散型サービス拒否攻撃に対して脆弱です。さまざまな場所から発信されたように見える多数の緊急コールを発信することは、レガシーシステム内で実行するのは困難ですが、IPベースの緊急サービス内で想像しやすい攻撃の例です。また、現在のシステムでは、ある国の攻撃者が別の国にある緊急サービスインフラストラクチャを攻撃することは非常に困難ですが、この攻撃はIPベースの緊急サービス内で可能です。
While manually mounting the attacks described in Section 2 is non-trivial, the attacks described in this document can be automated. While manually carrying out a location theft would require that the attacker be in proximity to the location being spoofed, or to collude with another end host, an attacker able to run code on an end host can obtain its location and cause an emergency call to be made. While manually carrying out a time-shifting attack would require that the attacker visit the location and submit it before the location information is considered stale, while traveling rapidly away from that location to avoid apprehension, these limitations would not apply to an attacker able to run code on the end host. While obtaining a PIDF-LO from a spoofed IP address requires that the attacker be on the path between the HELD requester and the LIS, if the attacker is able to run code requesting the PIDF-LO, retrieve it from the LIS, and then make an emergency call using it, this attack becomes much easier. To mitigate the risk of automated attacks, service providers can limit the ability of untrusted code (such as WebRTC applications written in JavaScript) to make emergency calls.
セクション2で説明されている攻撃を手動でマウントすることは簡単ではありませんが、このドキュメントで説明されている攻撃は自動化できます。場所の盗難を手動で実行するには、なりすましの場所に攻撃者が近づくか、別のエンドホストと共謀する必要がありますが、エンドホストでコードを実行できる攻撃者は、その場所を取得して緊急通話を行うことができます。製。タイムシフト攻撃を手動で実行するには、攻撃者がロケーションにアクセスし、ロケーション情報が古くなっていると見なされる前に送信する必要がありますが、そのロケーションから急いで離れて不安を回避する一方で、これらの制限は実行可能な攻撃者には適用されません。エンドホストのコード。スプーフィングされたIPアドレスからPIDF-LOを取得するには、攻撃者がHELDリクエスタとLISの間のパス上にいる必要がありますが、攻撃者がPIDF-LOを要求するコードを実行し、LISから取得してから、それを使用した緊急電話の場合、この攻撃ははるかに簡単になります。自動攻撃のリスクを軽減するために、サービスプロバイダーは信頼できないコード（JavaScriptで記述されたWebRTCアプリケーションなど）が緊急通話を発信する機能を制限できます。
Emergency services have three finite resources subject to denial-of-service attacks: the network and server infrastructure; call takers and dispatchers; and the first responders, such as firefighters and police officers. Protecting the network infrastructure is similar to protecting other high-value service providers, except that location information may be used to filter call setup requests, to weed out requests that are out of area. Even for large cities, PSAPs may only have a handful of call takers on duty. So, even if automated techniques are utilized to evaluate the trustworthiness of conveyed location and call takers can, by questioning the caller, eliminate many hoax calls, PSAPs can be overwhelmed even by a small-scale attack. Finally, first-responder resources are scarce, particularly during mass-casualty events.
緊急サービスには、サービス拒否攻撃の対象となる3つの有限リソースがあります。ネットワークとサーバーインフラストラクチャ。テイカーとディスパッチャーを呼び出します。消防士や警察官などの最初の対応者。ネットワークインフラストラクチャの保護は、位置情報を使用してコールセットアップリクエストをフィルタリングし、エリア外のリクエストを除外することを除いて、他の高価値サービスプロバイダーの保護と同様です。大都市であっても、PSAPは少数のコールテイカーしか担当していない場合があります。したがって、伝えられた場所の信頼性を評価するために自動化された手法が利用され、呼び出し担当者が発信者に質問することにより、多くのいたずら電話を排除できたとしても、PSAPは小規模な攻撃でさえ圧倒される可能性があります。最後に、最初の対応者のリソースは、特に大量災害の際には不足しています。
The emergency calling architecture described in [RFC6443] utilizes the PIDF-LO format defined in [RFC4119]. As described in the location privacy architecture [RFC6280], privacy rules that may include policy instructions are conveyed along with the location object.
[RFC6443]で説明されている緊急通報アーキテクチャは、[RFC4119]で定義されているPIDF-LO形式を利用しています。ロケーションプライバシーアーキテクチャ[RFC6280]で説明されているように、ポリシー命令を含む可能性のあるプライバシールールは、ロケーションオブジェクトとともに伝達されます。
The intent of the location privacy architecture was to provide strong privacy protections, as noted in [RFC6280], Section 1.1:
[RFC6280]のセクション1.1に記載されているように、ロケーションプライバシーアーキテクチャの目的は、強力なプライバシー保護を提供することでした。
A central feature of the Geopriv architecture is that location information is always bound to privacy rules to ensure that entities that receive location information are informed of how they may use it. These rules can convey simple directives ("do not share my location with others"), or more robust preferences ("allow my spouse to know my exact location all of the time, but only allow my boss to know it during work hours")... The binding of privacy rules to location information can convey users' desire for and expectations of privacy, which in turn helps to bolster social and legal systems' protection of those expectations.
Geoprivアーキテクチャの中心的な機能は、位置情報は常にプライバシールールにバインドされており、位置情報を受信するエンティティがその使用方法を確実に通知されるようにすることです。これらのルールは、単純なディレクティブ（「自分の現在地を他の人と共有しない」）またはより堅牢な設定（「配偶者に私の正確な現在地を常に知らせ、上司に勤務時間中にのみ知らせることを許可する」）を伝えることができます。 ...プライバシールールを位置情報にバインドすることで、プライバシーに対するユーザーの要望と期待を伝えることができます。これにより、社会的および法的システムによるそれらの期待の保護が強化されます。
However, in practice this architecture has limitations that apply within emergency and non-emergency situations. As noted in Section 1.2.2, concerns about hoax calls have led to restrictions on anonymous emergency calls. Caller identification (potentially asserted in SIP via P-Asserted-Identity and SIP Identity) may be used during emergency calls. As a result, in many cases location information transmitted within SIP messages can be linked to caller identity. For example, in the case of a signed LbyV, there are privacy concerns arising from linking the location object to identifiers to prevent replay attacks, as described in Section 3.1.
ただし、実際には、このアーキテクチャには、緊急時および非緊急時の状況に適用される制限があります。セクション1.2.2で述べたように、デマコールに関する懸念により、匿名の緊急コールが制限されています。発信者の識別（P-Asserted-IdentityおよびSIP Identityを介してSIPでアサートされる可能性がある）は、緊急通話中に使用できます。その結果、多くの場合、SIPメッセージ内で送信される位置情報は、発信者IDにリンクできます。たとえば、署名されたLbyVの場合、セクション3.1で説明されているように、位置オブジェクトを識別子にリンクしてリプレイ攻撃を防ぐことから生じるプライバシーの懸念があります。
The ability to observe location information during emergency calls may also represent a privacy risk. As a result, [RFC6443] requires transmission-layer security for SIP messages, as well as interactions with the location server. However, even where transmission-layer security is used, privacy rules associated with location information may not apply.
緊急通話中に位置情報を監視する機能は、プライバシーリスクを表す場合もあります。その結果、[RFC6443]には、SIPメッセージの送信層セキュリティと、ロケーションサーバーとの対話が必要です。ただし、伝送層セキュリティが使用されている場合でも、位置情報に関連付けられたプライバシールールは適用されない場合があります。
In many jurisdictions, an individual requesting emergency assistance is assumed to be granting permission to the PSAP, call taker, and first responders to obtain their location in order to accelerate dispatch. As a result, privacy policies associated with location are implicitly waived when an emergency call is initiated. In addition, when location information is included within SIP messages in either emergency or non-emergency uses, SIP entities receiving the SIP message are implicitly assumed to be authorized Location Recipients, as noted in [RFC5606], Section 3.2:
多くの管轄区域では、緊急支援を要求する個人が、急送を加速するためにPSAP、呼び出し担当者、および最初の応答者に位置を取得する許可を与えると想定されています。その結果、ロケーションに関連付けられたプライバシーポリシーは、緊急コールが開始されたときに暗黙的に放棄されます。また、[RFC5606]のセクション3.2に記載されているように、緊急または非緊急のいずれかの用途で位置情報がSIPメッセージに含まれている場合、SIPメッセージを受信するSIPエンティティは、承認された位置受信者であると暗黙的に見なされます。
Consensus has emerged that any SIP entity that receives a SIP message containing LI through the operation of SIP's normal routing procedures or as a result of location-based routing should be considered an authorized recipient of that LI. Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "no"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "no", as it is the passing to third parties that <retransmission-allowed> is meant to control.
SIPの通常のルーティング手順の操作を通じて、またはロケーションベースのルーティングの結果としてLIを含むSIPメッセージを受信するSIPエンティティは、そのLIの承認された受信者と見なす必要があるという合意が明らかになりました。この推定のため、あるSIPエレメントは、そのLOに含まれる<retransmission-allowed>が "no"に設定されていても、LIを別のSIPエレメントに渡すことがあります。これは、SIPメッセージの受け渡しを、再送信ではなく、許可された受信者への配信の一部と見なします。 <retransmission-allowed>が制御することを意図しているのはサードパーティへの受け渡しであるため、<retransmission-allowed>が「no」に設定されている場合、SIPエンティティは通常のルーティングの外部でこれらのメッセージを外部エンティティに渡すことは引き続き禁止されます。
Where LbyR is utilized rather than LbyV, it is possible to apply more restrictive authorization policies, limiting access to intermediaries and snoopers. However, this is not possible if the "authorization by possession" model is used.
LbyVではなくLbyRが使用されている場合、より制限的な許可ポリシーを適用して、中間者とスヌーパーへのアクセスを制限することが可能です。ただし、「所持による認可」モデルを使用している場合は不可能です。
[EENA] EENA, "False Emergency Calls", EENA Operations Document, Version 1.1, May 2011, <http://www.eena.org/ressource/ static/files/2012_05_04-3.1.2.fc_v1.1.pdf>.
[EENA] EENA、「False Emergency Calls」、EENA Operations Document、バージョン1.1、2011年5月、<http://www.eena.org/ressource/ static / files / 2012_05_04-3.1.2.fc_v1.1.pdf> 。
[GPSCounter] Warner, J. and R. Johnston, "GPS Spoofing Countermeasures", Los Alamos research paper LAUR-03-6163, December 2003.
[GPSCounter] Warner、J. and R. Johnston、 "GPS Spoofing Countermeasures"、Los Alamos研究論文LAUR-03-6163、2003年12月。
[Loc-Dependability] Thomson, M. and J. Winterbottom, "Digital Signature Methods for Location Dependability", Work in Progress, draft-thomson-geopriv-location-dependability-07, March 2011.
[Loc-Dependability] Thomson、M. and J. Winterbottom、「Digital Signature Methods for Location Dependability」、Work in Progress、draft-thomson-geopriv-location-dependability-07、2011年3月。
[NENA-i2] NENA 08-001, "NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)", Version 2, August 2010.
[NENA-i2] NENA 08-001、「拡張9-1-1サービス用のNENA暫定VoIPアーキテクチャ（i2）」、バージョン2、2010年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[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/info/rfc3261>.
[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/info/rfc3261>。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004, <http://www.rfc-editor.org/info/rfc3693>.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J.、J. Polk、 "Geopriv Requirements"、RFC 3693、February 2004、<http：//www.rfc-editor。 org / info / rfc3693>。
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004, <http://www.rfc-editor.org/info/rfc3694>.
[RFC3694] Danley、M.、Mulligan、D.、Morris、J。、およびJ. Peterson、「Threat Analysis of the Geopriv Protocol」、RFC 3694、2004年2月、<http://www.rfc-editor.org / info / rfc3694>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月、<http：/ /www.rfc-editor.org/info/rfc3748>。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004, <http://www.rfc-editor.org/info/rfc3863>.
[RFC3863]菅野博、藤本晋、クライン、G、ベイトマン、A、カー、W、J。ピーターソン、「プレゼンス情報データフォーマット（PIDF）」、RFC 3863、2004年8月、< http://www.rfc-editor.org/info/rfc3863>。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005, <http://www.rfc-editor.org/info/rfc4119>.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月、<http://www.rfc-editor.org/info/rfc4119>。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474] Peterson、J.およびC. Jennings、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（SIP）」、RFC 4474、2006年8月、<http://www.rfc-editor.org/info/rfc4474 >。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006, <http://www.rfc-editor.org/info/rfc4479>.
[RFC4479] Rosenberg、J。、「A Data Model for Presence」、RFC 4479、2006年7月、<http://www.rfc-editor.org/info/rfc4479>。
[RFC4740] Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006, <http://www.rfc-editor.org/info/rfc4740>.
[RFC4740] Garcia-Martin、M。、編、Belinchon、M.、Pallares-Lopez、M.、Canales-Valenzuela、C。、およびK. Tammi、「Diameter Session Initiation Protocol（SIP）Application」、RFC 4740 、2006年11月、<http://www.rfc-editor.org/info/rfc4740>。
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008, <http://www.rfc-editor.org/info/rfc5012>.
[RFC5012] Schulzrinne、H。およびR. Marshall、編、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、2008年1月、<http://www.rfc-editor.org/info/rfc5012>。
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008, <http://www.rfc-editor.org/info/rfc5069>.
[RFC5069] Taylor、T.、Ed。、Tschofenig、H.、Schulzrinne、H.、and M. Shanmugam、 "Security Threats and Requirements for Emergency Call Marking and Mapping"、RFC 5069、January 2008、<http：// www.rfc-editor.org/info/rfc5069>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009, <http://www.rfc-editor.org/info/rfc5491>.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月、<http：/ /www.rfc-editor.org/info/rfc5491>。
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009, <http://www.rfc-editor.org/info/rfc5606>.
[RFC5606] Peterson、J.、Hardie、T。、およびJ. Morris、「SIP Location Conveyanceの 'retransmission-allowed'の影響」、RFC 5606、2009年8月、<http://www.rfc-editor.org / info / rfc5606>。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月、<http://www.rfc-editor.org/info / rfc5751>。
[RFC5808] Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010, <http://www.rfc-editor.org/info/rfc5808>.
[RFC5808] Marshall、R。、編、「参照によるロケーションメカニズムの要件」、RFC 5808、2010年5月、<http://www.rfc-editor.org/info/rfc5808>。
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010, <http://www.rfc-editor.org/info/rfc5985>.
[RFC5985] Barnes、M。、編、「HTTP対応ロケーション配信（HELD）」、RFC 5985、2010年9月、<http://www.rfc-editor.org/info/rfc5985>。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011, <http://www.rfc-editor.org/info/rfc6280>.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月、<http://www.rfc-editor.org/info/rfc6280>。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011, <http://www.rfc-editor.org/info/rfc6442>.
[RFC6442] Polk、J.、Rosen、B。、およびJ. Peterson、「セッション開始プロトコルのロケーション伝達」、RFC 6442、2011年12月、<http://www.rfc-editor.org/info/rfc6442 >。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6443] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「Framework for Emergency Calling Using Internet Multimedia」、RFC 6443、2011年12月、<http：//www.rfc-editor。 org / info / rfc6443>。
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. Kuett, "Location Hiding: Problem Statement and Requirements", RFC 6444, January 2012, <http://www.rfc-editor.org/info/rfc6444>.
[RFC6444] Schulzrinne、H.、Liess、L.、Tschofenig、H.、Stark、B。、およびA. Kuett、「Location Hiding：Problem Statement and Requirements」、RFC 6444、2012年1月、<http：// www .rfc-editor.org / info / rfc6444>。
[RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)", RFC 6753, October 2012, <http://www.rfc-editor.org/info/rfc6753>.
[RFC6753] Winterbottom、J.、Tschofenig、H.、Schulzrinne、H。、およびM. Thomson、「HTTP対応のロケーション配信（HELD）を使用するロケーション逆参照プロトコル」、RFC 6753、2012年10月、<http：// www.rfc-editor.org/info/rfc6753>。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013, <http://www.rfc-editor.org/info/rfc6881>.
[RFC6881]ローゼン、B。およびJ.ポーク、「緊急通話をサポートする通信サービスの現在のベストプラクティス」、BCP 181、RFC 6881、2013年3月、<http://www.rfc-editor.org/info/ rfc6881>。
[RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. Patel, "Public Safety Answering Point (PSAP) Callback", RFC 7090, April 2014, <http://www.rfc-editor.org/info/rfc7090>.
[RFC7090] Schulzrinne、H.、Tschofenig、H.、Holmberg、C。、およびM. Patel、「Public Safety Answering Point（PSAP）Callback」、RFC 7090、2014年4月、<http：//www.rfc-editor .org / info / rfc7090>。
[RFC7199] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", RFC 7199, April 2014, <http://www.rfc-editor.org/info/rfc7199>.
[RFC7199] Barnes、R.、Thomson、M.、Winterbottom、J。、およびH. Tschofenig、「ポリシー管理のためのロケーション構成拡張」、RFC 7199、2014年4月、<http://www.rfc-editor.org / info / rfc7199>。
[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 >。
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, October 2014, <http://www.rfc-editor.org/info/rfc7375>.
[RFC7375] Peterson、J。、「Secure Telephone Identity Threat Model」、RFC 7375、2014年10月、<http://www.rfc-editor.org/info/rfc7375>。
[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax calls", Arab News, April 5, 2010, <http://www.arabnews.com/node/341463>.
[SA]「サウジアラビア-デマ通話の急増を非難したSIMの違法販売」、アラブニュース、2010年4月5日、<http://www.arabnews.com/node/341463>。
[SIP-Identity] Peterson, J., Jennings, C. and E. Rescorla, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-02, October 2014.
[SIP-Identity] Peterson、J.、Jennings、C. and E. Rescorla、 "Authenticated Identity Management in the Session Initiation Protocol（SIP）"、Work in Progress、draft-ietf-stir-rfc4474bis-02、October 2014。
[STIR] IETF, "Secure Telephone Identity Revisited (stir) Working Group", October 2013, <http://datatracker.ietf.org/wg/stir/charter/>.
[STIR] IETF、「Secure Telephone Identity Revisited（stir）Working Group」、2013年10月、<http://datatracker.ietf.org/wg/stir/charter/>。
[SWATing] "SWATing 911 Calls", Dispatch Magazine On-Line, April 6, 2013, <http://www.911dispatch.com/ swating-911-calls/>.
[SWEATing]「SWEATing 911 Calls」、Dispatch Magazine Online、2013年4月6日、<http://www.911dispatch.com/ swating-911-calls />。
[Swatting] "Don't Make the Call: The New Phenomenon of 'Swatting'", Federal Bureau of Investigation, February 4, 2008, <http://www.fbi.gov/news/stories/2008/february/ swatting020408>.
[スワッティング]「電話をかけないでください：「スワッティング」の新しい現象」、連邦捜査局、2008年2月4日、<http://www.fbi.gov/news/stories/2008/february/ swatting020408 >。
[TASMANIA] "Emergency services seek SIM-less calls block", ABC News Online, August 18, 2006, <http://www.abc.net.au/elections/ tas/2006/news/stories/1717956.htm?elections/tas/2006/>.
[タスマニア]「緊急サービスはSIMなしの通話ブロックを求めています」、ABCニュースオンライン、2006年8月18日、<http://www.abc.net.au/elections/ tas / 2006 / news / stories / 1717956.htm？選挙/タス/ 2006 />。
[UK] "Rapper makes thousands of prank 999 emergency calls to UK police", Digital Journal, June 24, 2010, <http://www.digitaljournal.com/article/293796?tp=1>.
[英国]「ラッパーが英国の警察に何千ものいたずら999緊急電話をかける」、デジタルジャーナル、2010年6月24日、<http://www.digitaljournal.com/article/293796?tp=1>。
Acknowledgments
謝辞
We would like to thank the members of the IETF ECRIT working group, including Marc Linsner and Brian Rosen, for their input at IETF 85 that helped get this document pointed in the right direction. We would also like to thank members of the IETF GEOPRIV working group, including Richard Barnes, Matt Lepinski, Andrew Newton, Murugaraj Shanmugam, and Martin Thomson for their feedback on previous versions of this document. Alissa Cooper, Adrian Farrel, Pete Resnick, Meral Shirazipour, and Bert Wijnen provided helpful review comments during the IETF last call.
このドキュメントを正しい方向に向けるのに役立つIETF 85での情報提供について、Marc LinsnerやBrian RosenなどのIETF ECRITワーキンググループのメンバーに感謝します。また、このドキュメントの以前のバージョンに関するフィードバックを提供してくださったRichard Barnes、Matt Lepinski、Andrew Newton、Murugaraj Shanmugam、Martin ThomsonなどのIETF GEOPRIVワーキンググループのメンバーにも感謝します。アリッサクーパー、エイドリアンファレル、ピートレズニック、メラルシラジプール、およびバートワイネンは、IETFの前回の電話中に有益なレビューコメントを提供しました。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Austria
Hannes Tschofenigオーストリア
EMail: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 United States
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027アメリカ合衆国
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 United States
バーナードアボバ（編集者）Microsoft Corporation One Microsoft Way Redmond、WA 98052 United States
EMail: bernard_aboba@hotmail.com