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
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.
この文書では、NAT（TURN）の周りにリレーを使用する必要なしに、ユーザーエージェント（UA）は、グローバルにルーティング可能なユーザエージェントのURI（GRUUs）とトラバーサルなどのメカニズムを利用することにより、匿名のセッション開始プロトコル（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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が定義されたときには不可能であった、プライバシーサービスを必要とせずに、そのユーザーのIDおよび関連情報を保留するUAを有効にします。
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-駆動プライバシーメカニズムは信頼ドメイン外のP-Asserted-Identityヘッダフィールドを転送しないようにプライバシーサービスを指示する[RFC3325]で定義されたRFC 3323使用の必要性を排除しないであろう。信頼ドメイン外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].
この文書では、UAは、このようなNAT（TURN）[RFC5766]の周りのリレーを使用してグローバルにルーティング可能なユーザエージェントのURI（GRUUs）[RFC5627]とトラバーサルなど、独自の利用SIP拡張のすべてのプライバシー機能を制御するガイドラインを定義しています。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
プライバシーに敏感な情報：ユーザーのIDを推測するために使用することができSIPメッセージを送信したユーザを特定する情報だけでなく、他の情報。
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.
この文書のプライバシーの考え方は、プライバシーに敏感な情報を隠しての行為です。ネットワーク・プライバシー（例えば、トポロジー隠蔽）の保護は、この文書の範囲外です。プライバシーに敏感な情報は、Contactヘッダーフィールドにユーザーの名前と所属（例えば、会社名）、およびIPアドレスまたはホスト名を明らかにすることができますから、ヘッダフィールド、のViaヘッダに表示名とURI（Uniform Resource Identifier）を含んでいますフィールドは、Call-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メッセージの一部のフィールドは、潜在的に、プライバシーに敏感な情報が含まれていますが、メッセージの意図した目的を達成するために不可欠なものではなく、任意の副作用なしに省略することができます。他のフィールドは、メッセージの意図した目的を達成するために不可欠であり、プライバシーに敏感な情報の開示を避けるために、匿名化された値が含まれている必要があります。連絡先、経由、およびSDPで第3節、URIを、ホスト名、および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.
[RFC5766] GRUU [RFC5627]を使用すると、順番、UAはまだ無名の機能であり、UAまたはユーザーのいずれかを識別していないメディアとシグナリングのためのURIとIPアドレスを取得することができます。
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.
ホスト名は、ユーザーのIDがそれらから推測することができますので、隠さする必要があるが、それらは常に重要なプライバシーの機密情報とはみなされません。
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.
UAがサポートし、この文書の範囲外の他の手段を介して機能匿名URIを得ることができない限りGRUUメカニズムを利用しなければならない機能の匿名URIを取得したいです。 GRUUを要求する登録要求を送信することによって、UAは、後でContactヘッダーフィールドのために使用することができる匿名の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.
機能的な匿名URIを取得するためにGRUU機構を使用するために、UAは、REGISTERリクエストにGRUUを要求しなければなりません。 「TEMP-GRUU」SIP URIパラメータと値はREGISTER応答に存在する場合、ユーザエージェントは、UAを表す匿名URIとして「TEMP-GRUU」の値を使用しなければなりません。これは、UAは、その地域のターゲットとしてこのURIを使用しなければならないこととUAを送信するローカルターゲットを必要とし、その後の要求と応答のContactヘッダーフィールドにこの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.
REGISTER要求への200（OK）応答には、「一時-GRUU」SIP URIパラメータが存在しない場合は、「一時-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.
UAは、プライバシーがユーザーから要求されたときに、機能匿名URIせずに要求を送信する前にユーザーに相談することを推奨されます。
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がどのように動作するかの性質のために、ドメイン名が常に明らかにされています。 Contactヘッダーフィールドにドメイン名を明らかにすることは懸念される場合は、サードパーティ製のGRUUサーバーの使用が可能な解決策であるが、これはこの文書の範囲外です。詳細については、セキュリティに関する考慮事項のセクションを参照してください。
4.2. Obtaining a Functional Anonymous IP Address Using the TURN Mechanism
4.2. TURNメカニズムを用いて機能匿名IPアドレスの取得
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.
匿名性がSDPおよびViaヘッダフィールドに使用するために所望される場合、いくつかの管理手段を介して機能匿名IPアドレスが付与されていないUAは、中継アドレス（リレーのIPアドレス）を取得しなければなりません。そのようなIPアドレスは、STUNサーバが中継として動作することを可能にするTURN機構を介してNATのセッショントラバーサルユーティリティ（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つの目的のために必要とされています。最初は、SIP要求のViaヘッダーフィールドに使用するためのものです。 、STUN中継サーバからIPアドレスを取得するSIP要求のViaヘッダフィールドにそのアドレスを使用して、そしてSTUN中継サーバに対してSIPリクエストを送信することによって、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.
第二は、メディアを受信するためのアドレスとしてSDPで使用するためのものです。 STUN中継サーバから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は、このような構成のフレームワーク一つ以上のSTUN（NAT用セッショントラバーサルユーティリティ）のアドレスを[-CONFIGを飲み]として手動または自動構成手段を介してであると仮定される[RFC5766]中継サーバは、匿名IPアドレスを取得します。
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.
ユーザーのプライバシーが要求されたときに、セクション5.1に示すように、UA、この文書に完全準拠は、SIPリクエストとレスポンスのすべての重要なUA-挿入プライバシーに敏感な情報を不明瞭か、隠す必要があります。 5.2節に示すように加えて、UAは、非クリティカルプライバシーに敏感な情報を隠すべきです。
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は、ダイアログ中のリクエストのためのUAに到達するために使用され、おそらくアウトオブこのようREFER要求[RFC3515]などのダイアログ要求、。 Contactヘッダーフィールドは、表示名を含めることができます。 Contactヘッダーフィールドは、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は、匿名のURI（「TEMP-GRUU」）を用いてContactヘッダーフィールドを匿名化しなければならない場合を除き、GRUU機構を介して得られました同等の機能匿名URIは、いくつかの他の手段により提供されます。 3xx応答を除いて他の要求と応答のため、要求を登録し、REGISTERリクエストに対する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はContactヘッダーフィールドに表示名を省略するか、「匿名」に表示名を設定しなければなりません。
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.
RFC 3261と3323は、設定「一口：anonymous@anonymous.invalid」をお勧めしますFromヘッダーフィールドにおけるSIP URIなどをユーザーのプライバシーが要求されたとき。これは、SIPアイデンティティからヘッダフィールドに実際のドメイン名を必要とするので、SIPアイデンティティメカニズム[RFC4474]は、メッセージに適用されている問題を提起します。
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を使用して、ヘッダフィールドから匿名。
The example form of the From header field of option 1 is as follows:
次のようにオプション1のFromヘッダフィールドの例示的形態です。
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
投稿者： "匿名" <一口：anonymous@anonymous.invalid>;タグ= 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を使用してヘッダフィールドから匿名化。
The example form of the From header field of option 2 is as follows:
次のようにオプション2のFromヘッダフィールドの例示的形態です。
From: "Anonymous" <sip:anonymous@example.com>;tag=1928301774
投稿者： "匿名" <一口：anonymous@example.com>;タグ= 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は、Fromヘッダーフィールドにそのドメイン名を隠すために、オプション1で行く必要があります。 SIPアイデンティティ機構がドメイン名に基づいて認証を使用するためしかし、SIPアイデンティティは、オプション1に従ってFromヘッダーフィールドと一緒に使用することができません。
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のFromヘッダーフィールドから明らかにされます。
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.
ユーザーは匿名性と強力なアイデンティティの両方を望んでいる場合は、解決策は、リクエストのFromヘッダーフィールドともSIP-アイデンティティ認証を提供することで使用するためのレコード（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.
プライバシーの配慮がなければ、Viaヘッダーフィールド一番下には、UAは、応答のための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.
同等の機能匿名IPアドレスが他の手段によって提供されない限り、本明細書をサポート匿名SIPリクエストを生成するUAは、TURN機構を介して得られた匿名のIPアドレスを使用して、ViaヘッダフィールドにIPアドレスを匿名化しなければなりません。
The UA SHOULD NOT include a host name in a Via header field.
UAは、Viaヘッダーフィールドにホスト名を含めないでください。
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.
存在する場合の等価機能匿名IPアドレスが他の手段によって提供されない限り、本明細書をサポートする匿名のSIPメッセージを生成するUAは、TURN機構を介して得られた匿名のIPアドレスを使用して、SDP内のIPアドレスを匿名化しなければなりません。
Refer to Section 4.2 for details on how to obtain an IP address through TURN.
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-情報としては、呼ば-ことで、返信するには、サーバー、件名、ユーザーエージェント、および警告）は、プライバシーに敏感な情報を含めることができます。
A UA generating an anonymous SIP message supporting this specification SHOULD NOT include any information that identifies the user in such optional header fields.
UAは、オプションヘッダフィールドにユーザを識別する情報を含むべきではないこの仕様をサポートする匿名のSIPメッセージを生成します。
This specification uses GRUU and TURN and inherits any security considerations described in these documents.
この仕様は、GRUUとTURNを使用し、これらの文書に記載されたセキュリティ上の考慮事項を継承します。
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箇所、ドメイン名が機能することが期待されているFromヘッダーフィールドとContactヘッダーフィールドは、主にあります。
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.
5.1.2項で説明したようにContactヘッダーフィールドが正しく機能するために、すべての回で有効なドメイン名が含まれている必要があり、一方、Fromヘッダーフィールドにドメイン名は、不明瞭にすることができます。
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.
注意：一般的に、デバイスは、受信機へ連絡先アドレスは表示されませんが、これは1つがメッセージ内のドメイン名を見つけることができないという意味ではありません。それは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を使用するUAのために、機密性は同じのAoRに登録することを許可されているかのAoRのための「REG」イベントパッケージ[RFC3680]に登録したときに、一時的なGRUUsを取得することが許可されている関係者には適用されません。これを制限するために、「REG」イベントパッケージの許可の認可ポリシーはのみ加入者が一時的GRUUsを受け取るためのAoRに登録することを許可することが示唆されます。このポリシーでは、一時的なGRUUの機密性は、「REG」イベントパッケージが使用されているかどうかを同じになります。
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.
1は、匿名性を確保したい場合は、ユーザーが求めると、このドキュメントの範囲外であるサードパーティの匿名化サービスに依存していることが示唆されます。
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.
サードパーティの匿名化サービスは、呼び出し側が完全にそのアイデンティティを保留することができ、呼び出し側のプロバイダとは提携を持っていないレジストラとTURNサービスを提供しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUUs）の取得と使用" を参照してください。
[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]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルNAT（TURN）の周りにリレーを使用してリレー拡張NAT（STUN）のセッショントラバーサルユーティリティに"、RFC 5766、2010年4月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680]ローゼンバーグ、J.、 "Aセッション開始プロトコル（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.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[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
まゆみ むなかた んっｔ こｒぽらちおん
EMail: munakata.mayumi@lab.ntt.co.jp
メールアドレス：munakata.mayumi@lab.ntt.co.jp
Shida Schubert NTT Corporation
市大SバートNTT法人
EMail: shida@ntt-at.com
メールアドレス：shida@ntt-at.com
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
電話：+81 422 59 7748 Eメール：URI ohba.takumi@lab.ntt.co.jp：http://www.ntt.co.jp