[要約] RFC 5767は、SIPにおけるUser-Agent-Driven Privacy Mechanism（ユーザーエージェント駆動型プライバシーメカニズム）に関する要約と目的を提供しています。このRFCの目的は、SIPユーザーエージェントがプライバシーを保護するための仕組みを提供することです。
Internet Engineering Task Force (IETF) M. Munakata
Request for Comments: 5767 S. Schubert
Category: Informational T. Ohba
ISSN: 2070-1721 NTT
April 2010
User-Agent-Driven Privacy Mechanism for SIP
SIPのユーザーエージェント駆動型プライバシーメカニズム
Abstract
概要
This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323.
このドキュメントでは、ユーザーエージェント（UA）が、グローバルにルーティング可能なユーザーエージェントURIS（Gruus）などのメカニズムを利用して、NAT（ターン）の周りのリレーを使用してトラバーサルを使用して、匿名を使用して匿名セッション開始プロトコル（SIP）メッセージを生成するためのガイドラインを定義しています。RFC 3323で定義されたプライバシーサービス。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc5767.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5767で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Concept of Privacy ..............................................3
4. Treatment of Privacy-Sensitive Information ......................3
4.1. Obtaining a Functional Anonymous URI Using the GRUU
Mechanism ..................................................4
4.2. Obtaining a Functional Anonymous IP Address Using
the TURN Mechanism .........................................5
5. UA Behavior .....................................................6
5.1. Critical Privacy-Sensitive Information .....................6
5.1.1. Contact Header Field ................................6
5.1.2. From Header Field in Requests .......................7
5.1.3. Via Header Field in Requests ........................8
5.1.4. IP Addresses in SDP .................................8
5.2. Non-Critical Privacy-Sensitive Information .................8
5.2.1. Host Names in Other SIP Header Fields ...............8
5.2.2. Optional SIP Header Fields ..........................9
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
[RFC3323] defines a privacy mechanism for the Session Initiation Protocol (SIP) [RFC3261], based on techniques available at the time of its publication. This mechanism relies on the use of a separate privacy service to remove privacy-sensitive information from SIP messages sent by a User Agent (UA) before forwarding those messages to the final destination. Since then, numerous SIP extensions have been proposed and standardized. Some of those enable a UA to withhold its user's identity and related information without the need for privacy services, which was not possible when RFC 3323 was defined.
[RFC3323]は、出版時に利用可能な手法に基づいて、セッション開始プロトコル（SIP）[RFC3261]のプライバシーメカニズムを定義します。このメカニズムは、これらのメッセージを最終目的地に転送する前に、ユーザーエージェント（UA）から送信されたSIPメッセージからプライバシーに敏感な情報を削除するために、個別のプライバシーサービスの使用に依存しています。それ以来、多数のSIP拡張機能が提案され、標準化されています。それらのいくつかは、RFC 3323が定義されたときには不可能でした。
The purpose of this document is not to obsolete RFC 3323, but to enhance the overall privacy mechanism in SIP by allowing a UA to take control of its privacy, rather than being completely dependent on an external privacy service.
このドキュメントの目的は、RFC 3323を廃止することではなく、外部プライバシーサービスに完全に依存するのではなく、UAがプライバシーを制御できるようにすることにより、SIPの全体的なプライバシーメカニズムを強化することです。
The UA-driven privacy mechanism defined in this document will not eliminate the need for the RFC 3323 usage defined in [RFC3325], which instructs a privacy service not to forward a P-Asserted-Identity header field outside the Trust Domain. In order to prevent forwarding a P-Asserted-Identity header field outside the Trust Domain, a UA needs to include the Privacy header field with value
このドキュメントで定義されているUA駆動型プライバシーメカニズムは、[RFC3325]で定義されているRFC 3323使用法の必要性を排除しません。これにより、プライバシーサービスは、P-Asserted-Identityヘッダーフィールドを信頼ドメインの外側に転送しないように指示します。P-Asserted-Identityヘッダーフィールドの信頼ドメインの外側に転送するのを防ぐために、UAはプライバシーヘッダーフィールドを価値のあるものに含める必要があります
'id' (Privacy:id) in the request, even when the UA is utilizing this specification.
UAがこの仕様を利用している場合でも、リクエストの「ID」（プライバシー：ID）。
This document defines a guideline in which a UA controls all the privacy functions on its own utilizing SIP extensions such as Globally Routable User Agent URIs (GRUUs) [RFC5627] and Traversal Using Relays around NAT (TURN) [RFC5766].
このドキュメントでは、Globally RoutableユーザーエージェントURIS（Gruus）[RFC5627]などのSIP拡張機能を使用して、UAがすべてのプライバシー機能を制御するガイドラインを定義し、NAT（ターン）[RFC5766]の周りのリレーを使用して横断することができます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
privacy-sensitive information: The information that identifies a user who sends the SIP message, as well as other information that can be used to guess the user's identity.
プライバシーに敏感な情報：SIPメッセージを送信するユーザーを識別する情報、およびユーザーのIDを推測するために使用できるその他の情報。
The concept of privacy in this document is the act of concealing privacy-sensitive information. The protection of network privacy (e.g., topology hiding) is outside the scope of this document. Privacy-sensitive information includes display-name and Uniform Resource Identifier (URI) in a From header field that can reveal the user's name and affiliation (e.g., company name), and IP addresses or host names in a Contact header field, a Via header field, a Call-ID header field, or a Session Description Protocol (SDP) [RFC4566] body that might reveal the location of a UA.
このドキュメントのプライバシーの概念は、プライバシーに敏感な情報を隠す行為です。ネットワークのプライバシーの保護（トポロジーが隠れているなど）は、このドキュメントの範囲外です。プライバシーに敏感な情報には、ヘッダーフィールドのディスプレイ名とユニフォームリソース識別子（URI）が含まれます。これは、ユーザーの名前と提携（会社名など）、および連絡先ヘッダーフィールドのIPアドレスまたはホスト名、ViaヘッダーのIPアドレスまたはホスト名が含まれます。フィールド、コールIDヘッダーフィールド、またはセッション説明プロトコル（SDP）[RFC4566] UAの位置を明らかにする可能性のあるボディ。
Some fields of a SIP message potentially contain privacy-sensitive information but are not essential for achieving the intended purpose of the message and can be omitted without any side effects. Other fields are essential for achieving the intended purpose of the message and need to contain anonymized values in order to avoid disclosing privacy-sensitive information. Of the privacy-sensitive information listed in Section 3, URIs, host names, and IP addresses in Contact, Via, and SDP are required to be functional (i.e., suitable for purpose) even when they are anonymized.
SIPメッセージの一部のフィールドには、プライバシーに敏感な情報が含まれている可能性がありますが、メッセージの意図された目的を達成するためには不可欠ではなく、副作用なしに省略できます。他のフィールドは、メッセージの意図された目的を達成するために不可欠であり、プライバシーに敏感な情報の開示を避けるために匿名化された値を含める必要があります。セクション3にリストされているプライバシーに敏感な情報、URIS、ホスト名、および連絡先、およびSDPのIPアドレスは、匿名化された場合でも機能的（つまり、目的に適した）である必要があります。
With the use of GRUU [RFC5627] and TURN [RFC5766], a UA can obtain URIs and IP addresses for media and signaling that are functional yet anonymous, and do not identify either the UA or the user.
Gruu [RFC5627]およびTurn [RFC5766]を使用して、UAは機能的でありながら匿名のメディアおよびシグナリングのURIとIPアドレスを取得し、UAまたはユーザーのいずれかを識別できません。
Instructions on how to obtain a functional anonymous URI and IP address are given in Section 4.1 and 4.2, respectively.
機能的な匿名のURIおよびIPアドレスを取得する方法に関する指示は、それぞれセクション4.1と4.2に記載されています。
Host names need to be concealed because the user's identity can be guessed from them, but they are not always regarded as critical privacy-sensitive information.
ユーザーの身元はそれらから推測できるため、ホスト名を隠す必要がありますが、それらは常に重要なプライバシーに敏感な情報と見なされるわけではありません。
In addition, a UA needs to be careful not to include any information that identifies the user in optional SIP header fields such as Subject and User-Agent.
さらに、UAは、サブジェクトやユーザーエージェントなどのオプションのSIPヘッダーフィールドにユーザーを識別する情報を含めないように注意する必要があります。
A UA wanting to obtain a functional anonymous URI MUST support and utilize the GRUU mechanism unless it is able to obtain a functional anonymous URI through other means outside the scope for this document. By sending a REGISTER request requesting GRUU, the UA can obtain an anonymous URI, which can later be used for the Contact header field.
機能的な匿名のURIを取得したいUAは、このドキュメントの範囲外の他の手段を通じて機能的な匿名URIを取得できない限り、Gruuメカニズムをサポートおよび利用する必要があります。Gruuを要求するレジスタリクエストを送信することにより、UAは匿名のURIを取得できます。これは後でコンタクトヘッダーフィールドに使用できます。
The detailed process on how a UA obtains a GRUU is described in [RFC5627].
UAがGRUUを取得する方法に関する詳細なプロセスは、[RFC5627]に記載されています。
In order to use the GRUU mechanism to obtain a functional anonymous URI, the UA MUST request GRUU in the REGISTER request. If a "temp-gruu" SIP URI parameter and value are present in the REGISTER response, the user agent MUST use the value of the "temp-gruu" as an anonymous URI representing the UA. This means that the UA MUST use this URI as its local target and that the UA MUST place this URI in the Contact header field of subsequent requests and responses that require the local target to be sent.
Gruuメカニズムを使用して機能的な匿名URIを取得するには、UAはレジスタリクエストでGruuを要求する必要があります。「Temp-Gruu」SIP URIパラメーターと値がレジスタ応答に存在する場合、ユーザーエージェントはUAを表す匿名のURIとして「Temp-Gruu」の値を使用する必要があります。これは、UAがこのURIをローカルターゲットとして使用する必要があり、UAがこのURIをその後のリクエストと応答のコンタクトヘッダーフィールドに配置する必要があることを意味します。
If there is no "temp-gruu" SIP URI parameter in the 200 (OK) response to the REGISTER request, a UA SHOULD NOT proceed with its anonymization process, unless something equivalent to "temp-gruu" is provided through some administrative means.
レジスタリクエストに対する200（OK）応答に「temp-gruu」SIP URIパラメーターがない場合、「Temp-gruu」に相当するものが何らかの管理手段を通じて提供されない限り、UAは匿名化プロセスを続行しないでください。
It is RECOMMENDED that the UA consult the user before sending a request without a functional anonymous URI when privacy is requested from the user.
ユーザーからプライバシーが要求された場合、機能的な匿名URIなしでリクエストを送信する前にUAがユーザーに相談することをお勧めします。
Due to the nature of how GRUU works, the domain name is always revealed when GRUU is used. If revealing the domain name in the Contact header field is a concern, use of a third-party GRUU server is a possible solution, but this is outside the scope of this document. Refer to the Security Considerations section for details.
Gruuの仕組みの性質により、Gruuが使用されるとドメイン名が常に明らかになります。コンタクトヘッダーフィールドでドメイン名を明らかにすることが懸念事項である場合、サードパーティのGruuサーバーの使用は可能なソリューションですが、これはこのドキュメントの範囲外です。詳細については、セキュリティに関する考慮事項セクションを参照してください。
A UA that is not provided with a functional anonymous IP address through some administrative means MUST obtain a relayed address (IP address of a relay) if anonymity is desired for use in SDP and in the Via header field. Such an IP address is to be derived from a Session Traversal Utilities of NAT (STUN) relay server through the TURN mechanism, which allows a STUN server to act as a relay.
いくつかの管理手段を介して機能的な匿名IPアドレスが提供されていないUAは、SDPおよびViaヘッダーフィールドで使用するために匿名性が必要な場合は、リレーアドレス（リレーのIPアドレス）を取得する必要があります。このようなIPアドレスは、ターンメカニズムを介してNAT（STUN）リレーサーバーのセッショントラバーサルユーティリティから導き出されます。これにより、STUNサーバーがリレーとして機能します。
Anonymous IP addresses are needed for two purposes. The first is for use in the Via header field of a SIP request. By obtaining an IP address from a STUN relay server, using that address in the Via header field of the SIP request, and sending the SIP request to the STUN relay server, the IP address of the UA will not be revealed beyond the relay server.
匿名のIPアドレスは、2つの目的に必要です。1つ目は、SIPリクエストのViaヘッダーフィールドで使用するためです。STUNリレーサーバーからIPアドレスを取得し、SIPリクエストのviaヘッダーフィールドでそのアドレスを使用し、SIPリクエストをStunリレーサーバーに送信することにより、UAのIPアドレスはリレーサーバーを超えて明らかになりません。
The second is for use in SDP as an address for receiving media. By obtaining an IP address from a STUN relay server and using that address in SDP, media will be received via the relay server. Also, media can be sent via the relay server. In this way, neither SDP nor media packets reveal the IP address of the UA.
2つ目は、メディアを受信するためのアドレスとしてSDPで使用するためです。スタンリレーサーバーからIPアドレスを取得し、SDPでそのアドレスを使用することにより、メディアはリレーサーバーを介して受信されます。また、メディアはリレーサーバーを介して送信できます。このように、SDPパケットもメディアパケットもUAのIPアドレスを明らかにしません。
It is assumed that a UA is either manually or automatically configured through means such as the configuration framework [SIPPING-CONFIG] with the address of one or more STUN (Session Traversal Utilities for NAT) [RFC5766] relay servers to obtain anonymous IP address.
UAは、1つ以上のスタン（NATのセッショントラバーサルユーティリティ）[RFC5766]リレーサーバーのアドレスを使用して、構成フレームワーク[Sipping-Config]などの手段を介して手動または自動構成のいずれかで構成されていると想定されています。
This section describes how to generate an anonymous SIP message at a UA.
このセクションでは、UAで匿名のSIPメッセージを生成する方法について説明します。
A UA fully compliant with this document MUST obscure or conceal all the critical UA-inserted privacy-sensitive information in SIP requests and responses as shown in Section 5.1 when user privacy is requested. In addition, the UA SHOULD conceal the non-critical privacy-sensitive information as shown in Section 5.2.
このドキュメントに完全に準拠しているUAは、ユーザープライバシーが要求されたときにセクション5.1に示されているように、SIPリクエストと応答のすべての重要なUAに挿入されたプライバシーに敏感な情報をすべて不明瞭または隠蔽する必要があります。さらに、UAは、セクション5.2に示すように、非批判的なプライバシーに敏感な情報を隠す必要があります。
Furthermore, when a UA uses a relay server to conceal its identity, the UA MUST send requests to the relay server to ensure request and response follow the same signaling path.
さらに、UAがリレーサーバーを使用してアイデンティティを隠す場合、UAは要求をリレーサーバーに送信して、リクエストと応答が同じシグナリングパスに従うことを確認する必要があります。
When using this header field in a dialog-forming request or response or in a mid-dialog request or response, this field contains the local target, i.e., a URI used to reach the UA for mid-dialog requests and possibly out-of-dialog requests, such as a REFER request [RFC3515]. The Contact header field can also contain a display-name. Since the Contact header field is used for routing further requests to the UA, the UA MUST include a functional URI even when it is anonymized.
このヘッダーフィールドをダイアログ形成リクエストまたは応答、またはダイアログの中間リクエストまたは応答で使用する場合、このフィールドにはローカルターゲット、つまりURIがMid-DialogリクエストのためにUAに到達するために使用されていました。参照要求[RFC3515]などのダイアログリクエスト。コンタクトヘッダーフィールドには、ディスプレイ名も含めることができます。コンタクトヘッダーフィールドはUAへのさらなる要求をルーティングするために使用されるため、UAには匿名化された場合でも機能性URIを含める必要があります。
When using this header field in a dialog-forming request or response or in a mid-dialog request or response, the UA MUST anonymize the Contact header field using an anonymous URI ("temp-gruu") obtained through the GRUU mechanism, unless an equivalent functional anonymous URI is provided by some other means. For other requests and responses, with the exception of 3xx responses, REGISTER requests and 200 (OK) responses to a REGISTER request, the UA MUST either omit the Contact header field or use an anonymous URI.
このヘッダーフィールドをダイアログ形成リクエストまたは応答、またはダイアログ中期リクエストまたは応答で使用する場合、UAは、Gruuメカニズムを介して取得した匿名のURI（「Temp-Gruu」）を使用してコンタクトヘッダーフィールドを匿名化する必要があります。同等の機能的匿名URIは、他の手段によって提供されます。他のリクエストと応答については、3XX応答、レジスタリクエスト、およびレジスタリクエストに対する200（OK）応答を除き、UAはコンタクトヘッダーフィールドを省略するか、匿名URIを使用する必要があります。
Refer to Section 4.1 for details on how to obtain an anonymous URI through GRUU.
Gruuから匿名のURIを取得する方法の詳細については、セクション4.1を参照してください。
The UA MUST omit the display-name in a Contact header field or set the display-name to "Anonymous".
UAは、連絡先ヘッダーフィールドに表示名を省略するか、ディスプレイ名を「匿名」に設定する必要があります。
Without privacy considerations, this field contains the identity of the user, such as display-name and URI.
プライバシーに関する考慮事項がなければ、このフィールドには、ディスプレイ名やURIなどのユーザーのIDが含まれています。
RFCs 3261 and 3323 recommend setting "sip:anonymous@anonymous.invalid" as a SIP URI in a From header field when user privacy is requested. This raises an issue when the SIP-Identity mechanism [RFC4474] is applied to the message, because SIP-Identity requires an actual domain name in the From header field.
RFCS 3261および3323は、ユーザープライバシーが要求されたときにヘッダーフィールドからのsip uriとして「sip：anonymous@anonymous.invalid」を設定することをお勧めします。Sip-Identityメカニズム[RFC4474]がメッセージに適用されると、これは問題が発生します。これは、Sip-IdentityがFrom Headerフィールドに実際のドメイン名を必要とするためです。
A UA generating an anonymous SIP message supporting this specification MUST anonymize the From header field in one of the two ways described below.
この仕様をサポートする匿名のSIPメッセージを生成するUAは、以下に説明する2つの方法のいずれかでヘッダーフィールドを匿名化する必要があります。
Option 1:
オプション1：
A UA anonymizes a From header field using an anonymous display-name and an anonymous URI following the procedure noted in Section 4.1.1.3 of RFC 3323.
UAは、RFC 3323のセクション4.1.1.3に記載されている手順に従って、匿名のディスプレイ名と匿名のURIを使用して、ヘッダーフィールドからAを匿名化します。
The example form of the From header field of option 1 is as follows:
オプション1のヘッダーフィールドからの例の例は次のとおりです。
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
Option 2:
オプション2：
A UA anonymizes a From header field using an anonymous display-name and an anonymous URI with user's valid domain name instead of "anonymous.invalid".
UAは、「anonymous.invalid」の代わりに、匿名のディスプレイ名と匿名のURIを使用して、匿名のURIを使用してヘッダーフィールドからAを匿名化します。
The example form of the From header field of option 2 is as follows:
オプション2のヘッダーフィールドの例の例は次のとおりです。
From: "Anonymous" <sip:anonymous@example.com>;tag=1928301774
A UA SHOULD go with option 1 to conceal its domain name in the From header field. However, SIP-Identity cannot be used with a From header field in accordance with option 1, because the SIP-Identity mechanism uses authentication based on the domain name.
UAはオプション1に移動して、From Headerフィールドにドメイン名を隠す必要があります。ただし、Sip-Identityメカニズムはドメイン名に基づいて認証を使用するため、Sip-Identityはオプション1に従ってHeaderフィールドで使用することはできません。
If a UA expects the SIP-Identity mechanism to be applied to the request, it is RECOMMENDED to go with option 2. However, the user's domain name will be revealed from the From header field of option 2.
UAがSIPアイデンティティメカニズムをリクエストに適用することを期待する場合、オプション2に使用することをお勧めします。ただし、ユーザーのドメイン名はオプション2のヘッダーフィールドから明らかになります。
If the user wants both anonymity and strong identity, a solution would be to use a third-party anonymization service that issues an Address of Record (AoR) for use in the From header field of a request and that also provides a SIP-Identity Authentication Service. Third-party anonymization service is out of scope for this document.
ユーザーが匿名性と強力なアイデンティティの両方を希望する場合、解決策は、リクエストのヘッダーフィールドで使用するためにレコードアドレス（AOR）を発行するサードパーティの匿名化サービスを使用することです。サービス。サードパーティの匿名化サービスは、このドキュメントの範囲外です。
Without privacy considerations, the bottommost Via header field added to a request by a UA contains the IP address and port or hostname that are used to reach the UA for responses.
プライバシーに関する考慮事項がなければ、ヘッダーフィールドを介したBottommostは、UAによるリクエストに追加され、ResponseのUAに到達するために使用されるIPアドレスとポートまたはホスト名が含まれています。
A UA generating an anonymous SIP request supporting this specification MUST anonymize the IP address in the Via header field using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided by some other means.
この仕様をサポートする匿名のSIPリクエストを生成するUAは、ターンメカニズムを介して取得した匿名のIPアドレスを使用して、ViaヘッダーフィールドのIPアドレスを匿名化する必要があります。
The UA SHOULD NOT include a host name in a Via header field.
UAには、Via Headerフィールドにホスト名を含めるべきではありません。
A UA generating an anonymous SIP message supporting this specification MUST anonymize IP addresses in SDP, if present, using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided by some other means.
この仕様をサポートする匿名のSIPメッセージを生成するUAは、SDPでIPアドレスを匿名化する必要があります。存在する場合、ターンメカニズムを介して取得した匿名IPアドレスを使用して、同等の機能的な匿名IPアドレスが他の手段によって提供されない限り。
Refer to Section 4.2 for details on how to obtain an IP address through TURN.
ターンでIPアドレスを取得する方法の詳細については、セクション4.2を参照してください。
A UA generating an anonymous SIP message supporting this specification SHOULD conceal host names in any SIP header fields, such as Call-ID and Warning header fields, if considered privacy-sensitive.
この仕様をサポートする匿名のSIPメッセージを生成するUAは、プライバシーに敏感であると見なされる場合、コールIDや警告ヘッダーフィールドなどのSIPヘッダーフィールドにホスト名を隠す必要があります。
Other optional SIP header fields (such as Call-Info, In-Reply-To, Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and Warning) can contain privacy-sensitive information.
その他のオプションのSIPヘッダーフィールド（Call-INFO、In-Reply-to、Organization、referened-by、Reply-To、Server、Subject、ユーザーエージェント、警告など）には、プライバシーに敏感な情報を含めることができます。
A UA generating an anonymous SIP message supporting this specification SHOULD NOT include any information that identifies the user in such optional header fields.
この仕様をサポートする匿名のSIPメッセージを生成するUAには、そのようなオプションのヘッダーフィールドでユーザーを識別する情報を含めるべきではありません。
This specification uses GRUU and TURN and inherits any security considerations described in these documents.
この仕様では、Gruuを使用して、これらのドキュメントに記載されているセキュリティ上の考慮事項をターンおよび継承します。
Furthermore, if the provider of the caller intending to obscure its identity consists of a small number of people (e.g., small enterprise, Small Office, Home Office (SOHO)), the domain name alone can reveal the identity of the caller.
さらに、そのアイデンティティを不明瞭にしようとする発信者のプロバイダーが少数の人々（たとえば、小規模、小さなオフィス、ホームオフィス（SOHO））で構成されている場合、ドメイン名のみが発信者のアイデンティティを明らかにすることができます。
The same can be true when the provider is large but the receiver of the call only knows a few people from the source of call.
プロバイダーが大きい場合でも同じことが言えますが、コールの受信者は、コールのソースから少数の人しか知っていません。
There are mainly two places in the message, the From header field and Contact header field, where the domain name is expected to be functional.
メッセージには主に2つの場所があります。これは、ドメイン名が機能すると予想されるヘッダーフィールドとコンタクトヘッダーフィールドです。
The domain name in the From header field can be obscured as described in Section 5.1.2, whereas the Contact header field needs to contain a valid domain name at all times in order to function properly.
From Headerフィールドのドメイン名は、セクション5.1.2で説明されているように不明瞭にすることができますが、接触ヘッダーフィールドは、適切に機能するために常に有効なドメイン名を含める必要があります。
Note: Generally, a device will not show the contact address to the receiver, but this does not mean that one cannot find the domain name in a message. In fact, as long as this specification is used to obscure identity, the message will always contain a valid domain name as it inherits key characteristics of GRUU.
注：一般的に、デバイスはレシーバーに連絡先アドレスを表示しませんが、これはメッセージ内のドメイン名が見つからないという意味ではありません。実際、この仕様がアイデンティティを不明瞭にするために使用される限り、メッセージにはGruuの重要な特性を継承するため、メッセージには常に有効なドメイン名が含まれます。
Note: For UAs that use a temporary GRUU, confidentiality does not extend to parties that are permitted to register to the same AoR or are permitted to obtain temporary GRUUs when subscribed to the 'reg' event package [RFC3680] for the AoR. To limit this, it is suggested that the authorization policy for the 'reg' event package permit only those subscribers authorized to register to the AoR to receive temporary GRUUs. With this policy, the confidentiality of the temporary GRUU will be the same whether or not the 'reg' event package is used.
注：一時的なGruuを使用するUASの場合、機密性は、同じAORに登録することが許可されている当事者には及ばないか、AORの「REG」イベントパッケージ[RFC3680]に登録したときに一時的なグルーを取得することが許可されていません。これを制限するために、「Reg」イベントパッケージの承認ポリシーは、AORに登録することを許可されたサブスクライバーのみが一時的なグルーを受け取ることを許可することを許可することが提案されています。このポリシーでは、「Reg」イベントパッケージが使用されているかどうかにかかわらず、一時的なGruuの機密性が同じになります。
If one wants to assure anonymization, it is suggested that the user seek and rely on a third-party anonymization service, which is outside the scope of this document.
A third-party anonymization service provides registrar and TURN service that have no affiliation with the caller's provider, allowing caller to completely withhold its identity.
サードパーティの匿名化サービスは、発信者のプロバイダーと提携していないレジストラとターンサービスを提供し、発信者がその身元を完全に差し控えることができます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（Gruus）の取得と使用」、RFC 5627、2009年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NAT周辺のリレーを使用したトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、RFC 5766、2010年4月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[SIPPING-CONFIG] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, September 2009.
[Sipping-Config] Channabasappa、S。、「セッション開始プロトコルユーザーエージェントプロファイル配信のフレームワーク」、2009年9月、進行中の作業。
Authors' Addresses
著者のアドレス
Mayumi Munakata NTT Corporation
Mayumi Munakata ntt Corporation
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
Shida Schubert NTT Corporation
EMail: shida@ntt-at.com
Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
Takumi Ohba NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585 Japan
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp
URI: http://www.ntt.co.jp