RFC3323 日本語訳
3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J.Peterson. November 2002. (Format: TXT=54116 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson Request for Comments: 3323 Neustar Category: Standards Track November 2002
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3323年のNeustarカテゴリ: 標準化過程2002年11月
A Privacy Mechanism for the Session Initiation Protocol (SIP)
セッション開始プロトコルのためのプライバシーメカニズム(一口)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.
このドキュメントはSession Initiationプロトコル(SIP)のためにプライバシーを支持して新しいメカニズムを定義します。 明確に、個人的なアイデンティティ情報を明かさないメッセージの創造にガイドラインを提供します。 仲介者のための新しい「プライバシーサービス」論理的な役割は、ユーザエージェントが納得できないといういくつかのプライバシー要件に答えるために定義されます。 最終的に、ユーザがプライバシーサービスから特定の機能を要求できる手段は提示されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . 4 3.1 When is Privacy Necessary? . . . . . . . . . . . . . . . . 5 3.2 User-Provided Privacy . . . . . . . . . . . . . . . . . . 6 3.3 Network-Provided Privacy . . . . . . . . . . . . . . . . . 7 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7 4.1 Constructing Private Messages . . . . . . . . . . . . . . 8 4.1.1 URIs, Display-Names and Privacy . . . . . . . . . . . . . 8 4.1.1.1 Display-Names . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.2 URI Usernames . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . 9 4.2 Expressing Privacy Preferences . . . . . . . . . . . . . . 11 4.3 Routing Requests to Privacy Services . . . . . . . . . . . 12 4.4 Routing Responses to Privacy Services . . . . . . . . . . 13 5. Privacy Service Behavior . . . . . . . . . . . . . . . . . 14
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 3。 Privacy. . . . . . . . . . . . . . . . . . . 4 3.1WhenのバラエティーはPrivacy Necessaryですか? . . . . . . . . . . . . . . . . 5 3.2 ユーザによって提供されたプライバシー. . . . . . . . . . . . . . . . . . 6 3.3のネットワークによって提供されたプライバシー. . . . . . . . . . . . . . . . . 7 4。 プライベート・メッセージ.84.1の.1URI、表示名、およびプライバシー. . . . . . . . . . . . . 8 4.1.1.1を構成するユーザエージェントの振舞い. . . . . . . . . . . . . . . . . . . 7 4.1が.94.1に.1.2URIをユーザ名と表示して命名します…; . . . . . . . . . . . . . 9 4.1.1.3 プライバシーサービス. . . . . . . . . . 13 5へのプライバシーサービス. . . . . . . . . . . 12 4.4ルート設定応答にプライバシー好み. . . . . . . . . . . . . . 11 4.3のルート設定要求を言い表すURIホスト名とIPアドレス. . . . . . . . . . . . . . 9 4.2。 プライバシー使用挙動. . . . . . . . . . . . . . . . . 14
Peterson Standards Track [Page 1] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[1ページ]。
5.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Session Privacy . . . . . . . . . . . . . . . . . . . . . 17
5.3 Applying User-Level Privacy Functions. . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . 22
5.1 ユーザレベルプライバシーを適用するヘッダープライバシー. . . . . . . . . . . . . . . . . . . . . . 16 5.2セッションプライバシー. . . . . . . . . . . . . . . . . . . . . 17 5.3が機能します。 . . . . . . . . . . 18 6. セキュリティ問題. . . . . . . . . . . . . . . . . 19 7。 IANA問題. . . . . . . . . . . . . . . . . . . 19引用規格. . . . . . . . . . . . . . . . . . . 20有益な参照. . . . . . . . . . . . . . . . . . 20作者のアドレス.21の承認. . . . . . . . . . . . . . . . . . . . . 21の完全な著作権宣言文. . . . . . . . . . . . . . . . . 22
1. Introduction
1. 序論
This document provides privacy requirements and mechanisms for the Session Initiation Protocol (SIP).
このドキュメントはSession Initiationプロトコル(SIP)にプライバシー要件とメカニズムを提供します。
Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. As identity is defined in this document, withholding the identity of a user will, among other things, render the other parties in the dialog unable to send new SIP requests to the user outside of the context of the current dialog.
プライバシーはコミュニケーション(明確にSIP対話)の交換で1以上から本書では人のアイデンティティの源泉徴収と定義された(そして、個人情報について話す)パーティーです。 これらのパーティーは潜在的にこれらのメッセージを扱っているメッセージ、そして/または、どんな仲介者の意図している目的地も入れます。 アイデンティティが本書では定義されるとき、ユーザのアイデンティティを差し控えると、相手は現在の対話の文脈の外で新しいSIP要求をユーザに送ることができない対話に特にするでしょう。
In SIP, identity is most commonly carried in the form of a SIP URI and an optional display-name. A SIP address-of-record has a form similar to an email address with a SIP URI scheme (for example, sip:alice@atlanta.com). A display-name is a string containing a name for the identified user (for example, "Alice"). SIP identities of this form commonly appear in the To and From header fields of SIP requests and responses. A user may have many identities that they use in different contexts.
SIPでは、アイデンティティはSIP URIのフォームと任意の表示名で最も一般的に運ばれます。 SIP記録されている住所には、SIP URI計画(例えば、一口: alice@atlanta.com )についてEメールアドレスと同様のフォームがあります。 表示名は特定されたユーザ(例えば、「アリス」)のための名前を含むストリングです。 このフォームのSIPのアイデンティティはSIP要求と応答のToとFromヘッダーフィールドに一般的に現れます。 ユーザには、それらが異なった文脈で使用する多くのアイデンティティがあるかもしれません。
There are numerous other places in SIP messages in which identity- related information can be revealed. For example, the Contact header field contains a SIP URI, one that is commonly as revealing as the address-of-record in the From. In some headers, the originating user agent can conceal identity information as a matter of local policy without affecting the operation of the SIP protocol. However, certain headers are used in the routing of subsequent messages in a dialog, and must therefore be populated with functional data.
アイデンティティが関係したSIPメッセージの情報を明らかにすることができる他の多数の場所があります。 例えば、ContactヘッダーフィールドはSIP URI(Fromの記録されている住所と一般的に同じくらい顕なもの)を含んでいます。 何人かのヘッダーでは、SIPプロトコルの操作に影響しないで、由来しているユーザエージェントはローカルの方針の問題としてアイデンティティ情報を隠すことができます。 しかしながら、確信しているヘッダーを対話にその後のメッセージのルーティングで使用されて、したがって、機能的なデータで居住しなければなりません。
Peterson Standards Track [Page 2] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[2ページ]。
The privacy problem is further complicated by proxy servers (also referred to in this document as "intermediaries" or "the network") that add headers of their own, such as the Record-Route and Via headers. Information in these headers could inadvertently reveal something about the originator of a message; for example, a Via header might reveal the service provider through whom the user sends requests, which might in turn strongly hint at the user's identity to some recipients. For these reasons, the participation of intermediaries is also crucial to providing privacy in SIP.
プライバシー問題は代理人を通してさらに複雑です。Record-ルートやViaヘッダーなどのそれら自身のヘッダーを加えるサーバ(また、本書では「仲介者」か「ネットワーク」に言及されます)。 これらのヘッダーの情報はメッセージの創始者に関してうっかり何かを明らかにするかもしれません。 例えば、Viaヘッダーはユーザが要求を送るサービスプロバイダーを明らかにするかもしれません。順番に、要求は強く何人かの受取人へのユーザのアイデンティティをほのめかすかもしれません。 これらの理由で、また、仲介者の参加もプライバシーをSIPに供給するのに重要です。
Two complimentary principles have guided the design of this privacy mechanism: Users are empowered to hide their identity and related personal information when they issue requests, but intermediaries and designated recipients of requests are entitled to reject requests whose originator cannot be identified.
2つの賞賛原則がこのプライバシーメカニズムのデザインを誘導しました: 彼らがいつ要求を出すかという彼らのアイデンティティと関連する個人情報を隠すのにユーザに権限を与えますが、要求の仲介者と指定された受取人に創始者を特定できない要求を拒絶する権利を与えます。
The privacy properties of only those specific headers enumerated in the core SIP specification ([1]), as opposed to headers defined by any existing or planned extension, are discussed in this document - however, the privacy mechanisms described in this document can be extended to support extensions.
本書ではどんな存在や計画された拡大でも定義されたヘッダーと対照的にコアSIP仕様([1])で数え上げられたそれらの特定のヘッダーだけのプライバシーの特性について議論します--しかしながら、拡大を支持するために本書では説明されたプライバシーメカニズムは広げることができます。
There are other aspects of the general privacy problem for SIP that are not addressed by this document. Most significantly, the mechanisms for managing the confidentiality of SIP headers and bodies, as well the security of session traffic, are not reconsidered here. These problems are sufficiently well addressed in the baseline SIP specification and related documents, and that no new mechanisms are required.
このドキュメントによって記述されないSIPのための一般的なプライバシー問題の他の局面があります。 最もかなり、また、SIPヘッダーとボディーの秘密性を管理するためのメカニズム、セッション交通のセキュリティ、ここで、再考されません。 これらの問題は基線SIP仕様と関連するドキュメントに十分よく記述されます、そして、どんな新しいメカニズムも必要ではありません。
This document begins with a section that provides a general framework and architecture for privacy in SIP (Section 3), followed by sections that detail user agent behavior (Section 4) and privacy service behavior (Section 5).
このドキュメントはユーザエージェントの振舞い(セクション4)を詳しく述べるセクションによって続かれたSIP(セクション3)とプライバシー使用挙動で一般的な枠組みと構造をプライバシーに提供するセクション(セクション5)で始まります。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[2]ということであり、対応する一口実現のために要件レベルを示すべきであるかをさせましょう。
Peterson Standards Track [Page 3] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[3ページ]。
3. Varieties of Privacy
3. プライバシーのバラエティー
A user may possess many identities that are used in various contexts; generally, identities are addresses-of-record which are bound to particular registrars (operated by the administrators of a domain) with whom SIP user agents register. The operators of these domains may be employers, service providers, or unaffiliated users themselves.
ユーザには、様々な文脈で使用される多くのアイデンティティがあるかもしれません。 一般に、アイデンティティはSIPユーザエージェントが登録する特定の記録係(ドメインの管理者によって操作されます)に縛られる記録のアドレスです。 これらのドメインのオペレータは、雇い主、サービスプロバイダー、または属しないユーザ自身であるかもしれません。
When a user voluntarily asserts an identity in a request, they are claiming that they can receive requests sent to that identity in that domain. Strictly speaking, privacy entails the restriction of the distribution of a specific identity and related personal information from some particular party or parties that are potentially recipients of the message. In particular, there are scenarios in which a party desiring anonymity may:
ユーザが自発的に要求におけるアイデンティティについて断言するとき、彼らは、そのドメインのそのアイデンティティに送られた要求は受け取ることができると主張しています。 厳密に言うと、プライバシーは潜在的にメッセージの受取人であるいくつかの特定のパーティーかパーティーからの特定のアイデンティティと関連する個人情報の分配の制限を伴います。 特に、匿名を望んでいるパーティーがそうするかもしれないシナリオがあります:
send a message and withhold an identity from the final
destination(s) while still communicating an identity to one or
more intermediaries
メッセージを送ってください、そして、まだ1人以上の仲介者へのアイデンティティを伝えている間、最終的な目的地からアイデンティティを差し控えてください。
send a message and withhold their identity from some or all
intermediaries, but still communicate an identity end-to-end to
the final destination(s)
メッセージを送ってください、そして、いくつかかすべての仲介者から彼らのアイデンティティを差し控えてくださいが、それでも、最終的な目的地のアイデンティティの終わりから端を伝えてください。(s)
withhold identity from both intermediaries and final
destination(s)
仲介者と最終的な目的地の両方からアイデンティティを差し控えてください。(s)
The result of withholding an identity is that the parties in question would be unable, for example, to attempt to initiate a new dialog with the anonymous party at a later time. However, the anonymous party still must be capable of receiving responses and new requests during the dialog in which it is participating.
アイデンティティを差し控えるという結果は例えば、問題のパーティーが、後で匿名のパーティーに伴う新しい対話を開始するのを試みることができないだろうということです。 しかしながら、匿名のパーティーはそれが関与している対話の間、応答と新しい要求を受け取るのがまだできなければなりません。
It may be desirable to restrict identity information on both requests and responses. Initially, it might seem unusual to suggest that a response has privacy concerns - presumably, the originator of the request knows who they were attempting to contact, so the identity of the respondent can hardly be confidential. However, some personal information in responses (such as the contact address at which the respondent is currently registered) is subject to privacy concerns and can be addressed by these mechanisms.
要求と応答の両方のアイデンティティ情報を制限するのは望ましいかもしれません。 初めは、応答にはプライバシーの問題があるのを示すのは珍しく思えるかもしれません--おそらく、要求の創始者が、それらが、だれに連絡するのを試みていたかを知っているので、応答者のアイデンティティはほとんど秘密であるはずがありません。 しかしながら、応答(応答者が現在登録される連絡先などの)における何らかの個人情報は、プライバシーの問題を受けることがあって、これらのメカニズムで記述できます。
Peterson Standards Track [Page 4] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[4ページ]。
3.1 When is Privacy Necessary?
3.1 Privacy Necessaryはいつですか?
Users may wish for identity information to be withheld from a given party for any number of reasons, for example:
ユーザは、例えば、アイデンティティ情報がいろいろな理由で与えられたパーティーから差し控えられて欲しいかもしれません:
Users might want to contact a particular party without revealing
their identity in order to impart information with which they
would not like to be associated
ユーザは情報を伝えるために彼らのアイデンティティを明らかにすることのない彼らが関連するようになりたがっていない特定のパーティーに連絡したがっているかもしれません。
Users might fear that the exposure of their identity or personal
information to some networks or destinations will make them a
target for unsolicited advertising, legal censure or other
undesirable consequences
ユーザは、いくつかのネットワークか目的地への彼らのアイデンティティか個人情報の露出がそれらを求められていない広告、法的な非難または他の望ましくない結果のための目標にすると恐れるかもしれません。
Users might want to withhold from participants in a session the
identity by which they are known to network intermediaries for the
purposes of billing and accounting
ユーザはセッションのときに関係者から彼らが支払いと会計の目的のために仲介者をネットワークでつなぐのが知られているアイデンティティを差し控えたがっているかもしれません。
When a user agent decides to send a request through a proxy server, it may be difficult for the originator to anticipate the final destination of that message. For that reason, users are advised not to base their estimation of their privacy needs on where they expect a message will go. For example, if a user sends a request to telephone number, they may believe that the final destination of the request will be a station in the public switched telephone network (PSTN) that is unable to inspect, say, SIP Contact headers, and therefore assume that it is safe to leave such headers in the clear; however, such a request might very well end up being retargeted by the network to a native SIP endpoint to which Contact headers are quite legible.
ユーザエージェントが、プロキシサーバを通して要求を送ると決めるとき、創始者がそのメッセージの最終的な目的地を予期するのは、難しいかもしれません。 その理由で、ユーザが、それらが、どこでメッセージが行くと予想するかを彼らのプライバシーの必要性に関する彼らの見積りに基礎づけないようにアドバイスされます。 例えば、ユーザが要求を電話番号に送るなら、彼らは、要求の最終的な目的地が明確でたとえばSIP Contactヘッダーを点検して、したがってそのようなヘッダーを置き去りにするのが安全であると思うことができない公衆電話交換網(PSTN)でステーションになると信じるかもしれません。 しかしながら、結局、ネットワークによってContactヘッダーが十分読みやすいネイティブのSIP終点にそのような要求によって非常によく「再-狙」われるかもしれません。
This document describes three degrees of privacy - one level of user-provided privacy, and two levels of network-provided privacy (header privacy and session privacy). How much privacy does a user need for any given session? Generally, if a user is seeking privacy, they're going to need as much of it as they can get. However, if a user knows of no privacy service, they must be content with user- provided privacy alone. Similarly, if a user knows of an anonymization service that can provide session privacy, but is unable to secure session traffic to prevent the anonymizer from possibly eavesdropping on the session, they might judge the loss of session privacy to be the lesser evil. The user might also be aware of exceptional conditions about the architecture in which the user agent is deployed that may obviate one or more privacy concerns.
このドキュメントは3段階のプライバシーについて説明します--1つのレベルのユーザによって提供されたプライバシー、および2つのレベルのネットワークによって提供されたプライバシー(ヘッダープライバシーとセッションプライバシー)。 ユーザはどんな与えられたセッションのためにもどのくらいのプライバシーを必要としますか? 一般に、ユーザがプライバシーを求めているなら、彼らは得ることができるようにそれの同じくらい多くを必要とするでしょう。 しかしながら、ユーザがプライバシーサービスを全く知らない場合にだけ、それらはユーザを提供している満足しているプライバシーであるに違いありません。 同様に、ユーザがセッションプライバシーを提供できるanonymizationサービスを知っていますが、anonymizerがことによるとセッションを盗み聞くのを防ぐためにセッション交通を保証できないなら、彼らは、セッションプライバシーの損失がレサー・イーブルであると判断するかもしれません。 また、ユーザも1つ以上のプライバシーの問題を取り除くかもしれないユーザエージェントが配備される構造に関する例外的な状態を知っているかもしれません。
Peterson Standards Track [Page 5] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[5ページ]。
A user may not always be the best judge of when privacy is required even under ideal circumstances, and thus privacy may in some architectures by applied by intermediaries without the user's explicit per-message request. By sending a request through intermediaries that can provide a privacy role, the user tacitly permits privacy functions to be invoked as needed.
ユーザはいつもプライバシーが理想的な状況でさえ必要である時に関する最も良い裁判官であるかもしれないというわけではありません、そして、その結果、プライバシーはユーザの1メッセージあたりの明白な要求のない仲介者による適用されるのによるいくつかの構造でそのような裁判官であるかもしれません。 プライバシーの役割を提供できる仲介者を通して要求を送ることによって、ユーザは、秘話機能が必要に応じて呼び出されることを暗に許可します。
It is also important that users understand that intermediaries may be unable to provide privacy functions requested by users. Requests for privacy may not be honored due to legal constraints, unimplemented or misconfigured features, or other exceptional conditions.
また、ユーザが、仲介者がユーザによって要求された秘話機能を提供できないかもしれないのを理解しているのも、重要です。 プライバシーを求める要求は、法的な規制のため光栄に思われなかったかもしれないか、非実行したか、または特徴、または他の例外的な状態をmisconfiguredしました。
Note that just as it is the prerogative of a user to conceal their identity, so it must also be the prerogative of proxy servers and other users to refuse to process requests from users whom they cannot identify. Therefore users should not just automatically withhold their identity for all requests and responses - inability to ascertain the identity of the originator of the request will frequently be grounds for rejection. Privacy should only be requested when the user has a need for it.
また、それがプロキシサーバと他のユーザの特権であるに違いなくユーザの特権がちょうどそれのように氏名を秘することになっていることに注意して、彼らが特定できないユーザから要求を処理するのを拒否してください。 したがって、ユーザはすべての要求と応答のためにちょうど自動的に彼らのアイデンティティを差し控えるべきではありません--要求の創始者のアイデンティティが頻繁になる拒絶の根拠を確かめることができないこと。 ユーザにそれの必要があると、プライバシーは要求されるだけであるべきです。
Further to this point, withholding some information in signaling might not be necessary for all user agents to ensure privacy. For example, user agents may acquire their IP addresses and hostnames dynamically, and these dynamic addresses may not reveal any information about the user whatsoever. In these cases, restricting access to hostnames (as described in Section 4.1.1.3) is unnecessary.
このポイントに加えて、すべてのユーザエージェントが秘密を守るのにシグナリングにおける何らかの情報を差し控えるのは必要でないかもしれません。 例えば、ユーザエージェントはダイナミックに彼らのIPアドレスとホスト名を習得するかもしれません、そして、これらのダイナミックなアドレスは全くユーザの少しの情報も明らかにしないかもしれません。これらの場合では、アクセスをホスト名(セクション4.1.1で.3について説明するので)に制限するのは不要です。
3.2 User-Provided Privacy
3.2 ユーザによって提供されたプライバシー
There is a certain amount of privacy that a user agent can provide itself. For example, the baseline SIP specification permits a user agent to populate the From header field of a request with an anonymous value. Users can take similar steps to avoid revealing any other unnecessarily identity information in related SIP headers (this is discussed further in Section 4.1.1).
ユーザエージェントがそれ自体を提供できるある量のプライバシーがあります。 例えば、基線SIP仕様は、ユーザエージェントが匿名の値で要求のFromヘッダーフィールドに居住することを許可します。 ユーザが明らかにするのを避けるために同様の方法を採ることができる、いかなる他のも不必要である、アイデンティティ情報、関連するSIPヘッダー(セクション4.1.1で、より詳しくこれについて議論する)で。
A user may have different privacy needs for a message if it traverses intermediaries rather than going directly end-to-end. A user may attempt to conceal things from intermediaries which are not concealed from the final destination, and vice versa. For example, using baseline SIP mechanisms, a user agent can encrypt SIP bodies end-to- end in order to prevent intermediaries from inspecting them. If a SIP message will not pass through intermediaries, however, this step might not be necessary (i.e., lower-layer security, without the addition of security for SIP bodies, could be sufficient).
ユーザには、終わるために直接終わるのに行くよりむしろ仲介者を横断するなら、メッセージの異なったプライバシーの必要性があるかもしれません。 ユーザは、仲介者からの最終的な目的地から隠されないものを隠すのを試みるかもしれません、そして、逆もまた同様です。 例えば、基線SIPメカニズムを使用して、ユーザエージェントは、仲介者が彼らを点検するのを防ぐためにSIPボディーエンドから終わりをコード化できます。 しかしながら、SIPメッセージが仲介者を通り抜けないなら、このステップは必要でないかもしれません(すなわち、下層セキュリティはSIPボディーのためのセキュリティの添加なしで十分であるかもしれません)。
Peterson Standards Track [Page 6] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[6ページ]。
Also note that if a dialog goes directly end-to-end between participants, however, it will not be possible to conceal the network addresses of the participants.
また、しかしながら、対話が関係者の間に終わるために直接終わるのに行くと、関係者のネットワーク・アドレスを隠すのが可能でないことに注意してください。
3.3 Network-Provided Privacy
3.3 ネットワークによって提供されたプライバシー
If a user is sending a request through intermediaries, a user agent can conceal its identity to only a limited extent without the intermediaries' cooperation. Also, some information can only be concealed from destination endpoints if an intermediary is entrusted to remove it.
ユーザが仲介者を通して要求を送るなら、ユーザエージェントは仲介者の協力なしで限られた程度だけまで氏名を秘することができます。 また、それを取り除くために仲介者をゆだねる場合にだけ、目的地終点から何らかの情報を隠すことができます。
For these reasons a user must have a way to request privacy from intermediaries, a means that allows users both to signal some indications of the desired privacy services, and to ensure that their call is routed to an intermediary that is capable of providing these services. A user may be aware of a specific third-party anonymizing host, one with which they have a pre-existing relationship, or a user may request that their local administrative domain provide privacy services.
ユーザにはともにいくつかの必要にプライバシーサービスのしるしに合図して、彼らの呼び出しが仲介者に発送されるのを保証するよう仲介者、ユーザを許容する手段からのプライバシーに要求する方法がなければならないこれらの理由で、それはこれらのサービスを提供できます。 ユーザは特定の第三者がホストをanonymizingするのを意識しているかもしれません、彼らが先在の関係を持っているものかユーザが、地元の管理ドメインがプライバシーサービスを提供するよう要求するかもしれません。
Intermediaries may also be empowered to apply privacy to a message without any explicit signaling from the originating user, since user agents may not always be cognizant or capable of requesting privacy when it is necessary.
また、少しも明白なシグナリングなしでプライバシーを由来しているユーザからメッセージに適用するのに仲介者に権限を与えるかもしれません、それが必要であるときに、ユーザエージェントがいつも認識力があるかプライバシーを要求できるかもしれないというわけではないので。
4. User Agent Behavior
4. ユーザエージェントの振舞い
There are three different ways that a user agent can contribute to the privacy of a request - by populating headers with values that reflect privacy requirements, by requesting further privacy services from the network, and by using cryptographic confidentiality to secure headers and bodies. Note that the last of these is outside the scope of this document.
ユーザエージェントがプライバシー要件を反映する値でヘッダーに居住することによって要求のプライバシーに寄付できる3つの異なった方法があります、ヘッダーとボディーを固定するためにネットワークで放送と、暗号の秘密性を使用することによってさらなるプライバシーサービスを要求することによって。 このドキュメントの範囲の外にこれらの最終があることに注意してください。
The mechanisms provided in this section assume that a user agent is sufficiently configurable that a user can select header values and provision privacy preferences (ideally on a per-call basis). If this isn't the case, it is possible that a user can route their call through a privacy service that is configured to groom signaling from this user agent in order to provide some of the function described below (see Section 5).
このセクションに提供されたメカニズムは、ユーザエージェントが十分構成可能であると仮定します。ユーザはヘッダー値と支給プライバシー好み(理想的に1呼び出しあたり1個のベースの)を選択できます。 これがそうでないなら、ユーザが以下で説明された機能のいくつかを提供するためにこのユーザエージェントからシグナリングの手入れをするために構成されるプライバシーサービスで彼らの呼び出しを発送できるのは(セクション5を見てください)、可能です。
Peterson Standards Track [Page 7] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[7ページ]。
4.1 Constructing Private Messages
4.1 プライベート・メッセージを構成すること。
Privacy starts with the user agent. The bulk of the steps that are required to conceal private information about the sender of a message are, appropriately enough, the sender's responsibility.
プライバシーはユーザエージェントから始まります。 メッセージの送付者に関する個人情報を隠すのに必要であるステップの大半が十分適切に送付者の責任です。
The following SIP headers, when generated by a user agent, can directly or indirectly reveal identity information about the originator of a message: From, Contact, Reply-To, Via, Call-Info, User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and Warning. Note that the use of an authentication system (such as the SIP Digest authentication method described in [1]) also usually entails revealing identity to one or more parties; for more information see Section 6.
ユーザエージェントによって発生すると、以下のSIPヘッダーは直接か間接的にメッセージの創始者のアイデンティティ情報を明らかにすることができます: に対して、を通して接触、答え、呼び出しインフォメーション、ユーザエージェント、組織、サーバ、対象、呼び出しID、そして、警告。 それに注意してください、認証システムの使用、(また、SIP Digest認証方法が[1])で説明したように通常、そのようなものは1回以上のパーティーへの顕なアイデンティティを伴います。 詳しい情報に関しては、セクション6を見てください。
The first and most obvious step is that user agents SHOULD not include any optional headers that might divulge personal information; there's certainly no reason for a user seeking privacy to include a Call-Info. Secondly, the user SHOULD populate URIs throughout the message in accordance with the guidelines given in Section 4.1.1. For example, users SHOULD create an anonymous From header field for the request. Finally, users MAY also need to request certain privacy functions from the network, as described in Section 4.2.
1番目の、そして、最も明白なステップはユーザエージェントSHOULDが個人情報を明かすかもしれないどんな任意のヘッダーも含んでいないということです。 確かに、Call-インフォメーションを含むようにプライバシーを求めているユーザの理由が全くありません。 第二に、セクション4.1.1で与えられたガイドラインによると、ユーザSHOULDはメッセージ中でURIに居住します。 例えば、ユーザSHOULDは要求のための匿名のFromヘッダーフィールドを作成します。 また、最終的に、ユーザは、セクション4.2で説明されるようにネットワークからある秘話機能を要求する必要があるかもしれません。
The Call-ID header, which is frequently constructed in a manner that reveals the IP address or hostname of the originating client, requires special mention. User agents SHOULD substitute for the IP address or hostname that is frequently appended to the Call-ID value a suitably long random value (the value used as the 'tag' for the From header of the request might even be reused).
Call-IDヘッダー(由来しているクライアントのIPアドレスかホスト名を明らかにする方法で頻繁に組み立てられる)は特記を必要とします。 SHOULDが頻繁にCall-IDに追加されるIPアドレスかホスト名に代入するユーザエージェントは適当に長い無作為の値(要求のFromヘッダーのための'タグ'が再利用さえされるかもしれないので使用される値)を評価します。
Note that if the user wants to conceal any of the above headers from intermediaries alone, without withholding them from the final destination of the message, users MAY also place legitimate values for these headers in encapsulated 'message/sip' S/MIME bodies as described in Section 23 of [1].
また、ユーザが仲介者から上のヘッダーのどれかを単独で隠したいなら、メッセージの最終的な目的地から彼らを差し控えないで、ユーザがこれらのヘッダーのために[1]のセクション23で説明されるように要約の'メッセージ/一口'S/MIME本体に正統の値を置くかもしれないことに注意してください。
4.1.1 URIs, Display-Names and Privacy
4.1.1 URI、表示名、およびプライバシー
A certain amount of privacy can be afforded by choosing to populate SIP headers with URIs and display-names that do not reveal any identity information. In some of the header fields (for example, the Reply-To and From headers), URIs are not used in further signaling within the current dialog. In others, like the Contact header, an inaccurate URI will result in a failure to route subsequent requests within the dialog.
URIと少しのアイデンティティ情報も明らかにしない表示名でSIPヘッダーに居住するのを選ぶことによって、ある量のプライバシーを提供できます。 そして、ヘッダーフィールドのいくつか、(例えば、Reply、-、Fromヘッダー)、URIは現在の対話の中でさらに合図する際に使用されません。 他のものでは、Contactヘッダーのように、不正確なURIは対話の中でその後の要求を発送しないことをもたらすでしょう。
Peterson Standards Track [Page 8] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[8ページ]。
4.1.1.1 Display-Names
4.1.1.1 表示名
It is a relatively common practice in email and other applications to use an assumed name in the display-name component of the From header field. Outside of a business context (especially in applications such as instant messaging or Internet gaming) the use of such aliases is unlikely to provide a cause for distrust.
メールと他のアプリケーションでは、Fromヘッダーフィールドの表示名のコンポーネントで偽名を使用するのは、比較的一般的な習慣です。 ビジネス文脈(特にインスタントメッセージングかインターネットゲーミングなどのアプリケーションにおける)の外では、そのような別名の使用が不信用の原因を提供しそうにはありません。
It is RECOMMENDED that user agents seeking anonymity use a display- name of "Anonymous".
匿名を求めているユーザエージェントが「匿名」の表示名を使用するのは、RECOMMENDEDです。
4.1.1.2 URI Usernames
4.1.1.2 URIユーザ名
The structure of a URI itself can reveal or conceal a considerable amount of personal information. Consider the difference between:
URI自体の構造は、かなりの量の個人情報を明らかにするか、または隠すことができます。 以下の違いを考えてください。
sip:jon.peterson@neustar.biz
一口: jon.peterson@neustar.biz
and
そして
sip:a0017@anonymous-sip.com
一口: a0017@anonymous-sip.com
From the former, the full name and employer of the party in question can easily be guessed. From the latter, you learn nothing other than that the party desires anonymity. In some cases, sufficient anonymity can be achieved by selecting an oblique URI. Today, the SIP specification recommends a URI with "anonymous" in the user portion of the From header.
前者から、問題のパーティーのフルネームと雇い主を容易に推測できます。 後者から、パーティーが匿名を望んでいる以外に、あなたは何も学びません。 いくつかの場合、斜線のURIを選択することによって、十分な匿名を達成できます。 今日、「匿名」がFromヘッダーのユーザ部分にある状態で、SIP仕様はURIを推薦します。
In some URIs, such as those that appear in Contact headers, it MAY also make sense to omit the username altogether, and provide only a hostname, like: sip:anonymous-sip.com
またそれがContactヘッダーに現れるものなどのように作るかもしれないいくつかのURIに、以下のように全体でユーザ名を省略するために理解して、ホスト名だけを提供してください。 sip.comである状態で匿名の以下をちびちび飲んでください。
4.1.1.3 URI Hostnames and IP Addresses
4.1.1.3 URIホスト名とIPアドレス
It is assumed by this document that the user that requests privacy wishes to receive future requests and responses within this dialog, but does not wish to reveal an identity that could be used to send new requests to him outside the scope of this dialog. For that reason, different treatment must be recommended for URIs that are used in the context of routing further requests in the dialog, as opposed to routing new requests outside the context of the dialog.
プライバシーを要求するユーザがこの対話の中に今後の要求と応答を受け取ることを願っていますが、この対話の範囲の外で新しい要求を彼に送るのに使用できたアイデンティティを明らかにしたがっていないとこのドキュメントによって思われます。 その理由で、さらなる要求を発送することの文脈で対話に使用されるURIのために異なった処理を推薦しなければなりません、対話の文脈の外に新しい要求を発送することと対照的に。
For headers indicating how the user would like to be contacted for future sessions (such as the From header), it might not immediately be obvious why changing the hostname would be necessary - if the username is 'anonymous', requests will not be routable to the anonymous user.
ユーザが今後のセッション(Fromヘッダーなどの)のためにどう連絡されたいかを示すヘッダーにおいて、ユーザ名が'匿名である'ならホスト名を変えるのが必要である理由、要求が匿名のユーザにとって発送可能にならないのは、すぐに、明白でないかもしれません。
Peterson Standards Track [Page 9] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[9ページ]。
Sometimes, merely changing the username will not be enough to conceal a user's identity. A user's SIP service provider might decisively reveal a user's identity (if it reflected something like a small company or a personal domain). So in this case, even though the URI in the From header would not dereference to the anonymous user, humans might easily guess the user's identity and know the proper form of their address-of-record.
時々、単にユーザ名を変えるのは、ユーザのアイデンティティを隠すために十分でないでしょう。 ユーザのSIPサービスプロバイダーは決定的にユーザのアイデンティティを明らかにするかもしれません(小会社や個人的なドメインのように反射したなら)。 この場合、FromヘッダーのURIは知らないでしょうが、匿名のユーザへの反参照、人間は、容易にユーザのアイデンティティを推測して、彼らの記録されている住所の適切な書式を知るかもしれません。
For these reasons, the hostname value 'anonymous.invalid' SHOULD be used for anonymous URIs (see [3] for more information about the reserved 'invalid' DNS TLD). The full recommended form of the From header for anonymity is (note that this From header, like all others, MUST contain a valid and unique 'tag=' parameter):
これらの理由で、ホスト名は'anonymous.invalid'SHOULDを評価します。匿名のURI(予約された'無効'DNS TLDに関する詳しい情報のための[3]を見る)のために、使用されてください。 匿名のためのFromヘッダーの完全なお勧めのフォームは(このFromヘッダーがすべての他のもののように有効でユニークな'タグ='パラメタを含まなければならないというメモ)です:
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
From: 「匿名」の<一口: anonymous@anonymous.invalid 、gt;、;=1928301774にタグ付けをしてください
For headers indicating how further requests in the current dialog should be routed (namely the Contact header, Via header, and session information in the SDP), there seems to be little that a user can do to disguise the existing URI, because users MUST provide a value that will allow them to receive further requests. In some cases, disguising or failing to provide the username, as described above, may create some level of privacy, but the hostname provides a more significant obstacle.
現在の対話におけるさらなる要求がどう発送されるべきであるかを(SDPのすなわち、Contactヘッダー、Viaヘッダー、およびセッション情報)示すヘッダーのために、ユーザが既存のURIを変装するためにすることができない少ししかはあるように思えます、ユーザが彼らがさらに受信できる値に要求を提供しなければならないので。 いくつかの場合、ユーザ名を提供する変装か失敗が上で説明されるように何らかのレベルのプライバシーを作成するかもしれませんが、ホスト名は、より重要な障害を提供します。
Is there much additional privacy in using an IP address rather than a hostname? It does prevent someone who casually inspects a message from gathering information that they might see otherwise. However, reverse-resolving such addresses is generally trivial, and substituting an IP address for a hostname could introduce some complications, for example due to NAT and firewall traversal concerns. Headers used in routing may also rely on certain DNS practices to provide services that would be lost if an IP address is used in place of a hostname.
ホスト名よりむしろIPアドレスを使用するのにおいて多くの追加プライバシーがありますか? それは彼らが別の方法で見るかもしれない集会情報から何気なくメッセージを点検するだれかを防ぎます。 しかしながら、一般に、そのようなものが記述する逆決議は些細です、そして、IPアドレスをホスト名の代わりに用いると、いくつかの複雑さが導入されるかもしれません、例えば、NATとファイアウォール縦断関心のため。 また、ルーティングで使用されるヘッダーは、IPアドレスがホスト名に代わって使用されるなら失われているサービスを提供するためにあるDNS習慣を当てにするかもしれません。
This document thus recommends that the host portion of URIs that are used in the routing of subsequent requests, such as URIs appearing in the Contact header, SHOULD NOT be altered by the user agent due to privacy considerations. If these headers require anonymization, the user requests that service from an intermediary, namely a privacy service.
その結果、このドキュメントは、Contactヘッダー、SHOULD NOTに現れるURIなどのその後の要求のルーティングで使用されるURIのホスト部分がプライバシー問題のためユーザエージェントによって変更されることを勧めます。 これらのヘッダーがanonymizationを必要とするなら、ユーザはすなわち、仲介者、プライバシーサービスからそのサービスを要求します。
Note that many of the considerations regarding the Contact header above apply equal well to SIP headers in which a hostname, rather than a URI, is used for some routing purpose (namely the Via header).
上のContactヘッダーに関する問題の多くがホスト名が何らかのルーティング目的(すなわち、Viaヘッダー)にURIよりむしろ使用されるSIPヘッダーに等しい井戸を当てはまることに注意してください。
Peterson Standards Track [Page 10] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[10ページ]。
4.2 Expressing Privacy Preferences
4.2 プライバシー好みを言い表すこと。
There are some headers that a user agent cannot conceal itself, because they are used in routing, that could be concealed by an intermediary that subsequently takes responsibility for directing messages to and from the anonymous user. The user agent must have some way to request such privacy services from the network. For that purpose, this document defines a new SIP header, Privacy, that can be used to specify privacy handling for requests and responses.
彼らがルーティングで使用されるので、ユーザエージェントが隠すことができない何人かのヘッダーがそれ自体であって、ユーザと、そして、匿名のユーザからのメッセージを指示することへの責任が次に取る仲介者はそれを隠すことができました。 ユーザエージェントには、ネットワークからそのようなプライバシーサービスを要求する何らかの方法がなければなりません。 そのために、このドキュメントは新しいSIPヘッダー、要求と応答のためのプライバシー取り扱いを指定するのに使用できるPrivacyを定義します。
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "header" / "session" / "user" / "none" / "critical"
/ token
プライバシー-hdrが「プライバシー」HCOLON priv-値の*と等しい、(「」、;priv値) priv-値が「ヘッダー」/「セッション」/「ユーザ」/「なにも」/「重要」/トークンと等しい
User agents SHOULD include a Privacy header when network-provided privacy (as described in Section 3.3) is required. Note that some intermediaries may also add the Privacy header to messages, including privacy services. However, such intermediaries SHOULD only do so if they are operating at a user's behest, for example if a user has an administrative arrangement with the operator of the intermediary that it will add such a Privacy header. An intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already specified.
ネットワークによって提供されたプライバシー(セクション3.3で説明されるように)が必要であるときに、ユーザエージェントSHOULDはPrivacyヘッダーを含んでいます。 また、何人かの仲介者がプライバシーサービスを含むメッセージにPrivacyヘッダーを追加するかもしれないことに注意してください。 しかしながら、例えば、ユーザが仲介者のオペレータによるそれが持っている管理アレンジメントを持っているなら、したがって彼らがユーザの命令で作動している場合にだけSHOULDがそうするそのような仲介者はそのようなPrivacyヘッダーを加えてください。 'なにも'priv-値が既に指定されるなら、仲介者は何らかの方法でPrivacyヘッダーを変更してはいけません。
The values of priv-value today are restricted to the above options, although further options can be defined as appropriate (see Section 7). Each legitimate priv-value can appear zero or one times in a Privacy header. The current values are:
今日のpriv-価値の値は上のオプションに制限されます、適宜さらなるオプションを定義できますが(セクション7を見てください)。 それぞれの正統のpriv-値はPrivacyヘッダーにゼロか1回現れることができます。 現行価値は以下の通りです。
header: The user requests that a privacy service obscure those
headers which cannot be completely expunged of identifying
information without the assistance of intermediaries (such as Via
and Contact). Also, no unnecessary headers should be added by the
service that might reveal personal information about the
originator of the request.
ヘッダー: ユーザは、プライバシーサービスが身元が分かる情報について仲介者(ViaやContactなどの)の支援なしで完全に梢消できるというわけではないそれらのヘッダーを見えなくするよう要求します。 また、要求の創始者に関する個人情報を明らかにするかもしれないサービスでどんな不要なヘッダーも加えるべきではありません。
session: The user requests that a privacy service provide
anonymization for the session(s) (described, for example, in a
Session Description Protocol [5] body) initiated by this message.
This will mask the IP address from which the session traffic would
ordinarily appear to originate. When session privacy is
requested, user agents MUST NOT encrypt SDP bodies in messages.
Note that requesting session privacy in the absence of any end-
to-end session encryption raises some serious security concerns
(see Section 5.2).
セッション: ユーザは、プライバシーサービスがこのメッセージによって開始されたセッション(例えば、Session記述プロトコル[5]ボディーでは、説明される)のためにanonymizationを提供するよう要求します。 これは通常、セッショントラフィックが起因するように見えるIPアドレスにマスクをかけるでしょう。 セッションプライバシーが要求されているとき、ユーザエージェントはメッセージでSDPボディーを暗号化してはいけません。 どんな終わりまでの終わりのセッション暗号化がないときセッションプライバシーを要求すると何らかの重大な安全上の配慮が上げられることに注意してください(セクション5.2を見てください)。
Peterson Standards Track [Page 11] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[11ページ]。
user: This privacy level is usually set only by intermediaries, in
order to communicate that user level privacy functions (as
discussed in Section 5.3) must be provided by the network,
presumably because the user agent is unable to provide them. User
agents MAY however set this privacy level for REGISTER requests,
but SHOULD NOT set 'user' level privacy for other requests.
ユーザ: 通常、このプライバシーレベルは単に仲介者によって設定されます、ネットワークが機能(セクション5.3で議論するように)を提供しなければならないそのユーザレベルプライバシーを伝えるために、ユーザエージェントがおそらくそれらを提供できないので。 しかしながら、ユーザエージェントはこのプライバシーレベルをREGISTER要求に設定するかもしれませんが、SHOULD NOTは'ユーザ'平らなプライバシーを他の要求に設定します。
none: The user requests that a privacy service apply no privacy
functions to this message, regardless of any pre-provisioned
profile for the user or default behavior of the service. User
agents can specify this option when they are forced to route a
message through a privacy service which will, if no Privacy header
is present, apply some privacy functions which the user does not
desire for this message. Intermediaries MUST NOT remove or alter
a Privacy header whose priv-value is 'none'. User agents MUST NOT
populate any other priv-values (including 'critical') in a Privacy
header that contains a value of 'none'.
なにも: ユーザは、プライバシーサービスが秘話機能を全くこのメッセージに適用しないよう要求します、サービスのユーザかデフォルトの振舞いのためのどんなあらかじめ食糧を供給されたプロフィールにかかわらず。 彼らがどんなPrivacyヘッダーも出席していないならユーザがこのメッセージのために望んでいないいくつかの秘話機能を適用するプライバシーサービスでやむを得ずメッセージを発送するとき、ユーザエージェントはこのオプションを指定できます。 仲介者は、priv-値が'なにも'であるPrivacyヘッダーを取り除いてはいけませんし、また変更してはいけません。 ユーザエージェントは'なにも'の値を含むPrivacyヘッダーでいかなる他のpriv-値(包含'重要な')にも居住してはいけません。
critical: The user asserts that the privacy services requested for
this message are critical, and that therefore, if these privacy
services cannot be provided by the network, this request should be
rejected. Criticality cannot be managed appropriately for
responses.
重要: ユーザは、このメッセージのために要求されたプライバシーサービスが重要であり、したがって、ネットワークがこれらのプライバシーサービスを提供できないなら、この要求が拒絶されるべきであると断言します。 応答のために適切に臨界に対処できません。
When a Privacy header is constructed, it MUST consist of either the value 'none', or one or more of the values 'user', 'header' and 'session' (each of which MUST appear at most once) which MAY in turn be followed by the 'critical' indicator.
Privacyヘッダーが組み立てられるとき、それは値の'なにも'か'重要な'インディケータが順番にあとに続くかもしれない値'ユーザ'、'ヘッダー'、および'セッション'(それのそれぞれが高々一度現れなければならない)の1つのどちらか以上から成らなければなりません。
The following table specifies extensions to Table 2 in [1].
以下のテーブルは[1]でTable2に拡大を指定します。
Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Privacy amrd o o o o o o
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG___________________________________________________________ プライバシーamrd o o o o o o
Header field SUB NOT PRK IFO UPD MSG ___________________________________________________________ Privacy o o o o o o
ヘッダーフィールドSUB NOT PRK IFO UPD MSG___________________________________________________________ プライバシーo o o o o o
4.3 Routing Requests to Privacy Services
4.3 プライバシーサービスへのルート設定要求
The most obvious way for a user agent to invoke the privacy function is to direct a request through an intermediary known to act as a privacy service. Doing so traditionally entails the configuration of pre-loaded Route headers that designate the privacy service.
ユーザエージェントが秘話機能を呼び出す最も明白な方法はプライバシーサービスとして機能するのが知られている仲介者を通して要求を指示することです。 そうするのはサービスにプライバシーを指定するプレロードされたRouteヘッダーの構成を伝統的に伴います。
Peterson Standards Track [Page 12] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[12ページ]。
It is RECOMMENDED that service providers couple the privacy service function with a local outbound proxy. Users can thereby send their messages that request privacy through their usual outbound route. Users should not assume, however, that the administrative domain that is the destination of the request would be willing and able to perform the privacy service function on their behalf. If the originating user wishes to keep their local administrative domain a secret, then they must use a third-party anonymization service outside of any of the principal administrative domains associated with the session.
サービスプロバイダーが地元の外国行きのプロキシにプライバシーサービス機能を結びつけるのは、RECOMMENDEDです。 その結果、ユーザはそれらの普通の外国行きのルートでプライバシーを要求する彼らのメッセージを送ることができます。 しかしながら、ユーザは、要求の目的地である管理ドメインが望んでいて彼らの代理にプライバシーサービス機能を実行できると仮定するべきではありません。 起因しているユーザが地元の管理ドメインを内緒にしたいなら、彼らはセッションに関連している主要な管理ドメインのどれかの外で第三者anonymizationサービスを利用しなければなりません。
It is highly RECOMMENDED that user agents use network or transport layer security, such as TLS, when contacting a privacy service. Ideally, users SHOULD establish a direct (i.e., single pre-loaded Route header) connection to a privacy service; this will both allow the user to inspect a certificate presented by the privacy service, and it will provide confidentiality for requests that will reduce the chances that the information that the privacy service will obscures is revealed before a message arrives at the privacy service. By establishing a direct connection to a privacy service, the user also eliminates the possibility that intermediaries could remove requests for privacy. If a direct connection is impossible, users SHOULD use a mechanism like SIPS to guarantee the use of lower-layer security all the way to the privacy service.
プライバシーサービスに連絡して、ユーザエージェントが使用するRECOMMENDEDは層のセキュリティを非常に、ネットワークでつなぐか、または輸送します、TLSなどのようにことです。 理想的に、ユーザSHOULDは(すなわち、独身のプレロードされたRouteヘッダー)ダイレクト接続をプライバシーサービスに確立します。 これで、ユーザはプライバシーサービスで提示された証明書を点検できるでしょう、そして、それは意志があいまいにするプライバシーサービスがメッセージの前に明らかにされるという情報がプライバシーサービスに到達するという可能性を小さくする要求に秘密性を前提とするでしょう。 また、ダイレクト接続をプライバシーサービスに確立することによって、ユーザは仲介者がプライバシーを求める要求を取り除くことができた可能性を排除します。 ダイレクト接続がどうしようもないなら、ユーザSHOULDは、下層セキュリティの使用をプライバシーサービスまでのいっぱいに保証するのにSIPSのようなメカニズムを使用します。
If a user agent believes that it is sending a request directly to a privacy service, it SHOULD include a Proxy-Require header containing a new option-tag, 'privacy', especially when the 'critical' priv- value is present in the Privacy header. That way, in the unlikely event that the user agent sends a request to an intermediary that does not support the extensions described in this document, the request will fail. Note that because of special privacy service
ユーザエージェントが信じているなら、直接プライバシーサービスに要求を送って、SHOULDであることはaを含んでいます。新しいオプションタグ、'プライバシー'を含んで、ヘッダーをProxy必要としてください、特に'重要な'priv値がPrivacyヘッダーに存在しているとき。 ありそうもないイベントにおけるユーザエージェントが本書では説明された拡大をサポートしない仲介者に要求を送るそのよう、要求は失敗するでしょう。 特別なプライバシーサービスのためにそれに注意してください。
behavior (described in Section 5), no subsequent intermediaries in the signaling path of the request will also need to the support the 'privacy' option-tag - once the privacy service has fulfilled all the required privacy functions, the 'privacy' option-tag is removed from the Proxy-Require header.
振舞い(セクション5では、説明される)、また、要求のシグナリング経路でどんなその後の仲介者も'プライバシー'オプションタグをサポートに必要としないでしょう--プライバシーサービスがすべての必要な秘話機能をいったん実現させる後、'プライバシー'オプションタグから取り外される、ヘッダーをProxy必要としてください。
4.4 Routing Responses to Privacy Services
4.4 プライバシーサービスへのルート設定応答
Making sure that responses will go through a privacy service is a little bit trickier. The path traversed by SIP responses is the same as the path over which the request traveled. Thus, the responding user agent, for example, cannot force a privacy service to be injected in the response path after it has received a request.
応答がプライバシーサービスを使い果たすのを確実にするのはほんの少し扱いにくいです。 SIP応答で横断された経路は要求が移動した経路と同じです。 したがって、要求を受け取った後に例えば、応じているユーザエージェントは応答経路でプライバシーサービスを強制的に注入させることができません。
Peterson Standards Track [Page 13] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[13ページ]。
What a responding user agent can do, however, is ensure that the path by which requests reach them traverses their privacy service. In some architectures, the privacy service function will be fulfilled by the same server to which requests for the local administrative domain are sent, and hence it will automatically be in the path of incoming requests. However, if this is not the case, the user will have to ensure that requests are directed through a third-party privacy service.
しかしながら、応じているユーザエージェントができることが要求がそれらに達する経路が彼らのプライバシーサービスを横断するのを確実にすることです。 いくつかのアーキテクチャでは、プライバシーサービス機能が地方の管理ドメインを求める要求が送られるのと同じサーバで実現するでしょう、そして、したがって、それは入って来る要求の経路に自動的にあるでしょう。 しかしながら、これがそうでないなら、ユーザは、要求が第三者プライバシーサービスで指示されるのを保証しなければならないでしょう。
One way to accomplish this is to procure an 'anonymous callback' URI from the third-party service and to distribute this as an address- of-record. A privacy service provider might offer these anonymous callback URIs to users in the same way that an ordinary SIP service provider grants addresses-of-record. The user would then register their normal address-of-record as a contact address with the third- party service.
これを達成する1つの方法は、第三者サービスから'匿名のコールバック'URIを調達して、記録のアドレスとしてこれを分配することです。 プライバシーサービスプロバイダーは普通のSIPサービスプロバイダーが記録のアドレスを与えるのと同じようにこれらの匿名のコールバックURIをユーザに提供するかもしれません。 そして、ユーザは連絡先として3番目のパーティーサービスにそれらの正常な記録されている住所を登録するでしょう。
Alternatively, a user agent could send REGISTER requests through a privacy service with a request for 'user' level privacy. This will allow the privacy service to insert anonymous Contact header URIs. Requests sent to the user's conventional address-of-record would then reach the user's devices without revealing any usable contact addresses.
あるいはまた、ユーザエージェントは'ユーザ'平らなプライバシーを求める要求と共に要求をREGISTERにプライバシーサービスで送ることができるでしょう。 これで、プライバシーサービスは匿名のContactヘッダーURIを挿入できるでしょう。 そして、どんな使用可能な連絡先も明らかにしないで、ユーザの従来の記録されている住所に送られた要求はユーザのデバイスに達するでしょう。
Finally, a user might generate a CPL ([7]) script that will direct requests to an anonymization service.
最終的に、ユーザは、CPL([7])がanonymizationサービスに要求を向けるスクリプトであると生成するかもしれません。
Users are also advised to use transport or network layer security in the response path. This may involve registering a SIPS URI and/or maintaining persistent TLS connections over which their user agent receives requests.
また、ユーザが応答経路における輸送かネットワーク層セキュリティを使用するようにアドバイスされます。 これは、SIPS URIを登録する、そして/または、彼らのユーザエージェントが要求を受け取る永続的なTLS接続を維持することを伴うかもしれません。
Privacy services MAY in turn route requests through other privacy services. This may be necessary if a privacy service does not support a particular privacy function, but it knows of a peer that does. Privacy services may also cluster themselves into networks that exchange session traffic between one another in order to further disguise the participants in a session, although no specific architecture or method for doing so is described in this document.
プライバシーサービスは他のプライバシーサービスで順番に要求を発送するかもしれません。 プライバシーサービスが特定の秘話機能をサポートしないなら、これが必要であるかもしれませんが、それはそれがする同輩を知っています。 また、プライバシーサービスはセッションのときにさらに関係者を変装するためにお互いの間でセッショントラフィックを交換するネットワークに自分たちをクラスタリングさせるかもしれません、そうするためのどんな特定のアーキテクチャもメソッドも本書では説明されませんが。
5. Privacy Service Behavior
5. プライバシー使用挙動
This document defines a new SIP logical role called a "privacy service". The privacy service role is instantiated by a network intermediary, frequently by entities that can act as SIP proxy servers. The function of a privacy service is to supply privacy functions for SIP messages that cannot be provided by user agents themselves.
このドキュメントは「プライバシーサービス」と呼ばれる新しいSIP論理的な役割を定義します。 プライバシーサービスの役割はネットワーク仲介者と、頻繁にSIPプロキシサーバとして演じられることができる実体によって例示されます。 プライバシーサービスの機能はユーザエージェントが自分たちで提供できないSIPメッセージに秘話機能を供給することです。
Peterson Standards Track [Page 14] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[14ページ]。
When a message arrives at a server that can act as a privacy service, the service SHOULD evaluate the level of privacy requested in a Privacy header. Usually, only the services explicitly requested should be applied. However, privacy services MAY have some means outside SIP of ascertaining the preferences of the user (such as a pre-arranged user profile) and therefore they MAY perform such other privacy functions without an explicit Privacy header. Performing even a user-level privacy function in a privacy service could be useful, for example, when a user is sending messages from a legacy client that does support the Privacy header, or a user agent that does not allow the user to configure the values of headers that could reveal personal information. However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header.
メッセージがプライバシーサービスとして機能できるサーバに到着するとき、サービスSHOULDはPrivacyヘッダーで要求されたプライバシーのレベルを評価します。 明らかに要求されたサービスだけが適用されるべきです。 しかしながら、プライバシーサービスはユーザ(根回しされたユーザ・プロファイルなどの)の好みを確かめるSIPの外にいくつかの手段を持っているかもしれません、そして、したがって、それらは明白なPrivacyヘッダーなしでそのような他の秘話機能を実行するかもしれません。 ユーザがPrivacyヘッダー、またはユーザに個人情報を明らかにすることができたヘッダーの値を構成させないユーザエージェントを支えるレガシークライアントからメッセージを送るとき、例えば、プライバシーサービスにおけるユーザレベル秘話機能さえ実行するのは役に立つかもしれません。 しかしながら、'なにも'のPrivacyヘッダー価値がメッセージで指定されるなら、プライバシーサービスは、Privacyヘッダーを少しの秘話機能も実行してはいけなくて、取り除いてはいけませんし、また変更してはいけません。
Privacy services MUST implement support for the 'none' and 'critical' privacy tokens, and MAY implement any of other privacy levels described in Section 4.2 as well as any extensions that are not detailed in this document. In some cases, the privacy service will not be capable of fulfilling the requested level of privacy. If the 'critical' privacy level is present in the Privacy header of a request, then if the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header then it MUST fail the request with a 500 (Server Error) response code. The reason phrase of the status line of the response SHOULD contain appropriate text indicating that there has been a privacy failure as well as an enumeration of the priv-value(s) which were not supported by the privacy service (the reason phrase SHOULD also respect any Accept- Language header in the request if possible).
プライバシーサービスは、'なにも'と'重要な'プライバシートークンのサポートを実装しなければならなくて、本書では詳しく述べられない少しの拡大と同様にセクション4.2で説明された他のプライバシーレベルのいずれも実装するかもしれません。 いくつかの場合、プライバシーサービスは要求されたレベルのプライバシーを実現させることができないでしょう。 '重要な'プライバシーレベルが要求のPrivacyヘッダーに存在していて、プライバシーサービスがPrivacyヘッダーで指定されたプライバシーのレベルのすべてを実行できないなら、500(サーバError)応答コードに応じて、それは要求に失敗しなければなりません。 応答SHOULDの状況表示行の理由句はプライバシーサービス(また、できれば、句のSHOULDが要求におけるどんなAccept言語ヘッダーも尊敬する理由)でサポートされなかったpriv-価値の列挙と同様にプライバシー失敗があったのを示す適切なテキストを含んでいます。
When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the corresponding priv-value from the Privacy header - otherwise, any other privacy service involved with routing this message might unnecessarily apply the same function, which in many cases would be undesirable. When the last priv-value (not counting 'critical') has been removed from the Privacy header, the entire Privacy header MUST be removed from a message.
プライバシーサービスが働くとき、プライバシーレベルに対応する機能の1つはPrivacyヘッダーに記載しました、それ。SHOULDはPrivacyヘッダーから対応するpriv-値を取り除きます--さもなければ、このメッセージを発送するのにかかわるいかなる他のプライバシーサービスも不必要に、同じ機能(多くの場合、望ましくないもの)を適用するかもしれません。 Privacyヘッダーから最後のpriv-値('重要'を数えない)を取り除いたとき、メッセージから全体のPrivacyヘッダーを取り除かなければなりません。
When the privacy service removes the entire Privacy header, if the message is a request, the privacy service MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request.
いつからプライバシーサービスがメッセージが要求であるなら全体のPrivacyヘッダーを取り除いて、また、プライバシーサービスがどんな'プライバシー'オプションタグも取り除かなければならないか、要求のヘッダーフィールドをProxy必要としてください。
Peterson Standards Track [Page 15] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[15ページ]。
5.1 Header Privacy
5.1 ヘッダープライバシー
If a privacy level of 'header' is requested, then the originating user has asked the privacy service to help to obscure headers that might otherwise reveal information about the originator of the request. However, the values that have been so obscured must be recoverable when further messages in the dialog need to be routed to the originating user agent. In order to provide these functions the privacy service must frequently act as a transparent back-to-back user agent (B2BUA).
'ヘッダー'のプライバシーレベルが要求されるなら、起因しているユーザは別の方法で要求の創始者の情報を明らかにするかもしれない不鮮明なヘッダーに助けるプライバシーサービスを招きました。 しかしながら、対話におけるさらなるメッセージが、起因しているユーザエージェントに発送される必要があるとき、そのようにあいまいにされた値は回復可能であるに違いありません。 これらの機能を提供するために、プライバシーサービスは透明な背中合わせのユーザエージェント(B2BUA)として頻繁に機能しなければなりません。
Firstly, a request for header privacy entails that the server SHOULD NOT add any headers to the message that reveal any identity or personal information, including the following: Call-Info, Server, and Organization. All of these provide optional information that could reveal facts about the user that has request anonymity.
ヘッダープライバシー限嗣相続を求めるサーバSHOULD NOTがメッセージへのどんなアイデンティティも明らかにするどんなヘッダーも加えるというまず第一に要求か以下を含む個人情報: 呼び出しインフォメーション、サーバ、および組織。 これらはすべて、要求匿名を持っているユーザに関する事実を明らかにすることができた任意の情報を提供します。
Privacy services operating on requests SHOULD remove all Via headers that have been added to the request prior to its arrival at the privacy service (a practice referred to as "Via stripping") and then SHOULD add a single Via header representing themselves. Note that the bottommost such Via header field value in a request contains an IP address or hostname that designates the originating client, and subsequent Via header field values may indicate hosts in the same administrative domain as the client. No Via stripping is required when handling responses.
プライバシーサービス(「ストリップを通して」と呼ばれた習慣)への到達の前に要求に追加されたすべてのViaヘッダーはSHOULDが取り除く要求を作動させて、次にSHOULDを作動させるプライバシーサービスは自分たちの代理をする独身のViaヘッダーを加えます。 IPアドレスか起因しているクライアントを任命するホスト名と、その後のViaヘッダーフィールドが、要求におけるそのようなViaヘッダーフィールド価値が含む最低部がクライアントと同じ管理ドメインでホストを示すかもしれないことに注意してくださいというように評価します。 応答を扱うとき、Viaストリップは必要ではありません。
Contact headers are added by user agents to both requests and responses. A privacy service SHOULD replace the value of the Contact header in a message with a URI that does not dereference to the originator of the message (such as the anonymous URI described in Section 4.1.1.3). The URI that replaces the existing Contact header field value MUST dereference to the privacy service.
接触ヘッダーはユーザエージェントによって要求と応答の両方に加えられます。 プライバシーサービスSHOULDはメッセージのContactヘッダーの値をメッセージの創始者にどんな反参照もしないURIに取り替えます(匿名のURIとしてのそのようなものはセクション4.1.1で.3について説明しました)。 既存のContactヘッダーフィールド価値を置き換えるURIはプライバシーサービスへの反参照がそうしなければなりません。
In a manner similar to Via stripping, a privacy service SHOULD also strip any Record-Route headers that have been added to a request before it reaches the privacy service - though note that no such headers will be present if there is only one hop between the originating user agent and the privacy service, as is recommended above. Such Record-Route headers might also divulge information about the administrative domain of the client.
また、Viaストリップ、プライバシーサービスと同様の方法で、SHOULDは上でお勧めであることでそこであるならそのようなどんなヘッダーも出席しないというメモが起因しているユーザエージェントとプライバシーサービスの間でワンバウンドであるだけであって、そのままですが、プライバシーサービスに達する前に要求に追加されたどんなRecord-ルートヘッダーも裸にします。 また、そのようなRecord-ルートヘッダーはクライアントの管理ドメインの情報を明かすかもしれません。
For the purposes of this document, it is assumed that the privacy service has locally persisted the values of any of the above headers that are so removed, which requires the privacy service to keep a pretty significant amount of state on a per-dialog basis. When further requests or responses associated with the dialog reach the privacy service, it MUST restore values for the Via, Record-
このドキュメントの目的のために、プライバシーサービスが局所的に、そのように取り除かれる上のヘッダーのどれかの値を固持したと思われます。(値は、1対話あたり1個のベースにかなりかなりの量の状態を維持するためにプライバシーサービスを必要とします)。 対話に関連しているさらなる要求か応答がプライバシーサービスに達すると、Viaのために値を回復しなければなりません、Record
Peterson Standards Track [Page 16] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[16ページ]。
Route/Route or Contact headers that it has previously removed in the interests of privacy. There may be alternative ways (outside the scope of this document) to perform this function that do not require keeping state in the privacy service (usually means that involve encrypting and persisting the values in the signaling somehow).
ルート/ルートか以前に、それがあるContactヘッダーがプライバシーのために取り外しました。 プライバシーサービス(通常どうにかシグナリングにおける値を暗号化して、固持することを伴う手段)で状態を維持するのを必要としないこの機能を実行する代替の方法(このドキュメントの範囲の外の)があるかもしれません。
The following procedures are RECOMMENDED for handling the Record- Route header field of requests and responses, which provides specialchallenges to a privacy service:
以下の手順はプライバシーサービスにspecialchallengesを提供する要求と応答のRecordルートヘッダーフィールドを扱うためのRECOMMENDEDです:
When a privacy service is processing (on behalf of the originator) a request that contains one or more Record-Route header field values, the privacy service must strip these values from the request and remember both the dialog identifiers and the ordered Record-Route header field values. As described above, it must also replace the Contact header field with a URI indicating itself. When a response with the same dialog identifiers arrives at the privacy service, the privacy service must reapply any Record-Route header field values to the response in the same order, and it must then add a URI representing itself to the Record-Route header field of the response. If the response contains Record-Route header field values of its own, these must also be included (in order) in the Record-Route header field after the URI representing the privacy service.
プライバシーサービスが1つ以上のRecord-ルートヘッダーフィールド値を含む要求を処理しているとき(創始者を代表して)、プライバシーサービスは、要求からこれらの値を剥取って、対話識別子と命令されたRecord-ルートヘッダーフィールド値の両方を覚えていなければなりません。 また、上で説明されるように、それはContactヘッダーフィールドをそれ自体を示すURIに取り替えなければなりません。 同じ対話識別子がある応答がプライバシーサービスに到達すると、プライバシーサービスは、どんなRecord-ルートもヘッダーフィールド値であると同次における応答に再び使わなければなりません、そして、次に、それは応答のRecord-ルートヘッダーフィールドにそれ自体を表すURIを加えなければなりません。 また、応答がそれ自身のRecord-ルートヘッダーフィールド値を含んでいるなら、これらはプライバシーサービスを表すURIの後のRecord-ルートヘッダーフィールドにおいて含まれている(in order)であるに違いありません。
Note that when a privacy service is handling a request and providing privacy on behalf of the destination of the request, providing privacy for Record-Route headers downstream of the privacy service is significantly more complicated. This document recommends no way of statefully restoring those headers if they are stripped.
プライバシーサービスが要求の目的地を代表して要求を扱って、プライバシーを提供しているとき、プライバシーサービスのRecord-ルートヘッダー川下にプライバシーを提供するのがかなり複雑であることに注意してください。 このドキュメントは彼らが剥取られるならstatefullyにそれらのヘッダーを返す方法を全く推薦しません。
5.2 Session Privacy
5.2 セッションプライバシー
If a privacy level of 'session' is requested, then the user has requested that the privacy service anonymize the session traffic (e.g., for SIP telephony calls, the audio media) associated with this dialog.
'セッション'のプライバシーレベルが要求されるなら、ユーザは、プライバシーサービスがこの対話に関連しているセッショントラフィック(例えば、SIP電話呼び出しのためのオーディオメディア)をanonymizeするよう要求しました。
The SIP specification dictates that intermediaries such as proxy servers cannot inspect and modify message bodies. The privacy service logical role MUST therefore act as a back-to-back user agent in order to provide media privacy, effectively terminating and re- originating the messages that initiate a session (although in support of session privacy the privacy service does not need to alter headers characterizing the originator or destination when the request is re- originated). In order to introduce an anonymizer for session traffic, the privacy service needs to control a middlebox [8] that can provide an apparent source and sink for session traffic. The details of the implementation of an anonymizer, and the modifications
SIP仕様は、プロキシサーバなどの仲介者がメッセージ本体を点検して、変更できないと決めます。 したがって論理的な役割が事実上、セッションを開始するメッセージを終えて、再溯源して(プライバシーサービスはセッションプライバシーを支持して要求が再溯源されるとき創始者か目的地について描写するヘッダーを変更する必要はありませんが)、メディアプライバシーを提供するために背中合わせのユーザエージェントとして機能させなければならないプライバシーサービス。 セッショントラフィックのためにanonymizerを導入するために、プライバシーサービスは、仮想点音源と流し台をセッショントラフィックに提供できるmiddlebox[8]を制御する必要があります。 anonymizerの実装の詳細、および変更
Peterson Standards Track [Page 17] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[17ページ]。
that must be made to the Session Description Protocol (SDP [5]) bodies in the messages that initiate a session are outside the scope of this document.
それをSession記述プロトコルにしなければなりません。(このドキュメントの範囲の外にセッションを開始するメッセージのSDP[5])ボディーがあります。
The risk, of course, of using such an anonymizer is that the anonymizer itself is party to your communications. For that reason, requesting session-level privacy without resort to some sort of end- to-end security for the session traffic (with RTP [6] media, for example, SRTP [4]) is NOT RECOMMENDED.
もちろん、anonymizerによるanonymizer自身があなたのコミュニケーションに関係するというそのようなものを使用することでは、ことですリスクであり。 それに関して、推論してください、セッショントラフィックのためにリゾートなしである種の終わりまでの終わりのセキュリティにセッションレベルプライバシーを要求して。(RTPと共に、[6]メディア、例えば、SRTP[4])はNOT RECOMMENDEDです。
5.3 Applying User-Level Privacy Functions at a Privacy Service
5.3 プライバシーサービスのときにユーザレベル秘話機能を適用すること。
If a privacy level of 'user' is requested, then the originating user has requested that privacy services perform the user-level privacy functions described in Section 4.1.
'ユーザ'のプライバシーレベルが要求されるなら、起因しているユーザは、プライバシーサービスがセクション4.1で説明されたユーザレベル秘話機能を実行するよう要求しました。
Note that the privacy service MUST remove any non-essential informational headers that have been added by the user agent, including the Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To.
そして、プライバシーサービスがユーザエージェントによって加えられるどんな不要不急な情報のヘッダーも取り除かなければならないことに注意してください、Subjectを含んでいて、Call-インフォメーション、Organization、User-エージェント、Reply、-、Inは答えます。
Significantly, user-level privacy could entail the modification of the From header, changing it from its original value to an anonymous value. Prior to the current issue of the SIP specification, the modification of the values of the To and From headers by intermediaries was not permitted, and would result in improper dialog matching by the endpoints. Currently, dialog matching uses only the tags in the To and From headers, rather than the whole header fields. Thus, under the new rules the URI values in the To and From headers themselves could be altered by intermediaries. However, some legacy clients might consider it an error condition if the value of the URI in the From header altered between the request and the response.
かなり、ユーザレベルプライバシーはFromヘッダーの変更を伴うかもしれません、それを元の値から匿名の値に変えて。 SIP仕様の最新号の前に、仲介者によるToとFromヘッダーの値の変更は、受入れられないで、終点のそばで不適当な対話マッチングをもたらすでしょう。 現在、対話マッチングは全体のヘッダーフィールドよりむしろToとFromヘッダーでタグだけを使用します。 したがって、新しい規則の下では、仲介者はToとFromヘッダー自体のURI値を変更できました。 しかしながら、FromヘッダーのURIの値が要求と応答の間で変わるなら、何人かのレガシークライアントが、それがエラー条件であると考えるでしょうに。
Also, performing user-level privacy functions MAY entail the modification of the Call-ID header, since the Call-ID commonly contains a hostname or IP address corresponding to the originating client. This field is essential to dialog matching, and it cannot be altered by intermediaries.
また、ユーザレベル秘話機能を実行すると、Call-IDヘッダーの変更は伴われるかもしれません、Call-IDが一般的に起因しているクライアントにとって、対応するホスト名かIPアドレスを含んでいるので。 この分野は対話マッチングに不可欠です、そして、仲介者はそれを変えることができません。
Therefore, any time that a privacy service needs to modify any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent.
したがって、プライバシーサービスが、プライバシーのためにどんな対話に合うヘッダーも変更する必要がある何時でも推論して、透明な背中合わせのユーザエージェントとしてのSHOULD条例です、そして、それは対話に合うヘッダーの前の値を固持しなければなりません。 起因しているユーザエージェントに送られるどんなメッセージでもこれらの値を回復しなければなりません。
Peterson Standards Track [Page 18] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[18ページ]。
6. Security Considerations
6. セキュリティ問題
Messages that request privacy require confidentiality and integrity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the privacy service) could see the very personal information that the user has asked the privacy service to obscure.
プライバシーを要求するメッセージが秘密性と保全を必要とします。 保全がなければ、アイデンティティが情報であると潜在的に暴露して、要求された秘話機能は、格下げされるか、または排除されるかもしれません。 秘密性がなければ、ネットワーク(または、ユーザとプライバシーサービスの間のどんな仲介者も)の立ち聞きする者はユーザがあいまいにするサービスをプライバシーに尋ねたという非常に個人的な情報を見ることができました。
All of the network-provided privacy functions in this document entail a good deal of trust for the privacy service. Users should only trust privacy services that are somehow accountable to them.
ネットワークによって提供された秘話機能のすべてがプライバシーサービスのために本書では多くの信頼を伴います。 ユーザはどうにか責任があるプライバシーサービスをそれらに任せるだけであるべきです。
Operators of privacy services should be aware that in the eyes of downstream entities, a privacy service will be the only source to which anonymous messages can be traced.
プライバシーサービスのオペレータは川下の実体の目では、プライバシーサービスが唯一のソースになるのを匿名のメッセージをたどることができる意識しているべきです。
Note that authentication mechanisms, including the Digest authentication method described in the SIP specification, are outside the scope of the privacy considerations in this document. Revealing identity through authentication is highly selective, and may not result in the compromise of any private information. Obviously, users that do not wish to reveal their identity to servers that issue authentication challenges MAY elect not to respond to such challenges.
プライバシー問題の範囲の外にSIP仕様で説明されたDigest認証方法を含む認証機構が本書ではあることに注意してください。 認証による顕なアイデンティティは、非常に選択していて、どんな個人情報の感染ももたらさないかもしれません。 明らかに、問題認証が挑戦するサーバへの彼らのアイデンティティを明らかにしたがっていないユーザは、そのような挑戦に応じないのを選ぶかもしれません。
7. IANA Considerations
7. IANA問題
This document defines a new SIP header field called "Privacy" that allows a user agent to request a certain degree of privacy for a message. This behavior associated with this header is specified in Section 4.2. This header has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントはユーザエージェントがメッセージのためにある度合いのプライバシーを要求できる「プライバシー」と呼ばれる新しいSIPヘッダーフィールドを定義します。 このヘッダーに関連しているこの振舞いはセクション4.2で指定されます。 このヘッダーは http://www.iana.org/assignments/sip-parameters の下にサブ登録しているヘッダーに加えられます。
Header name: Privacy
Compact form: none defined
ヘッダー名: プライバシーCompactは形成します: 定義されなかったなにも
This document also creates an IANA registry for values that populate the Privacy header. This registry should be indexed by priv-value tokens and should contain a short semantic description of the new value. The current values of the "Privacy" header are as follows:
また、このドキュメントはPrivacyヘッダーに居住する値のためのIANA登録を作成します。 この登録は、priv-値のトークンによって索引をつけられるべきであり、新しい価値の短い意味記述を含むべきです。 「プライバシー」ヘッダーの現行価値は以下の通りです:
o user: Request that privacy services provide a user-level privacy
function
o ユーザ: プライバシーサービスがユーザレベル秘話機能を提供するよう要求してください。
o header: Request that privacy services modify headers that cannot
be set arbitrarily by the user (Contact/Via).
o ヘッダー: を通してプライバシーサービスがユーザが任意に用意ができさせることができないヘッダーを変更するよう要求してください、(接触/、)
Peterson Standards Track [Page 19] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[19ページ]。
o session: Request that privacy services provide privacy for session
media
o セッション: プライバシーサービスがセッションメディアにプライバシーを提供するよう要求してください。
o none: Privacy services must not perform any privacy function
o なにも: プライバシーサービスは少しの秘話機能も実行してはいけません。
o critical: Privacy service must perform the specified services or
fail the request
o 批判的: プライバシーサービスは、指定されたサービスを実行しなければならないか、または要求に失敗しなければなりません。
New values for the "Privacy" header can only be defined by IETF Consensus including RFC publication (RFC 2434). IANA registration for the "Privacy" header field values is required along with the RFC publication.
RFC公表(RFC2434)を含むIETF Consensusは「プライバシー」ヘッダーのための新しい値を定義できるだけです。 「プライバシー」ヘッダーフィールド値のためのIANA登録がRFC公表と共に必要です。
Authors of extensions to the SIP protocol that expose personal information about the participants in sessions are advised against extending the "Privacy" header - rather, it is preferable to create new identity mechanisms whose privacy can be managed by the user agent without the agency of intermediaries.
SIPプロトコルへのセッションのときに関係者に関する個人情報を露出する拡大の作者は「プライバシー」ヘッダーを広げないようにアドバイスされます--むしろ、ユーザエージェントが仲介者の政府機関なしでプライバシーに対処できる新しいアイデンティティメカニズムを作成するのは望ましいです。
This document also defines a new SIP option-tag, 'privacy', that represents support for the extension defined in this document.
また、このドキュメントは新しいSIPオプションタグ、本書では定義された拡大のサポートを表す'プライバシー'を定義します。
Normative References
引用規格
[1] 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.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC
2606, June 1999.
[3] イーストレークとD.とA.パニツ、「予約された最高平らなDNS名」、RFC2606、1999年6月。
Informative References
有益な参照
[4] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E.,
Naslund, M. and K. Normann, "The Secure Real Time Transport
Protocol", Work in Progress.
[4] 「安全なリアルタイムのトランスポート・プロトコル」というBaugher、M.、マグリュー、D.、オラン、D.、ブロム、R.、カラーラ、E.、ジーター、M.、およびK.ノーマンは進行中で働いています。
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
Peterson Standards Track [Page 20] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[20ページ]。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[6]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[7] Lennox, J. and H. Schulzrinne, "CPL: A Language for User Control
of Internet Telephony Services", Work in Progress
[7] レノックス、J.、およびH.Schulzrinne、「CPL:」 「インターネット電話サービスのユーザコントロールのための言語」、処理中の作業
[8] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002.
[8]Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリトル、A.、A.Rayhan、および「Middlebox通信アーキテクチャと枠組み」、RFC3303(2002年8月)
Author's Address
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Acknowledgments
承認
The author would like to thank Allison Mankin, Rohan Mahy, Eric Rescorla, Mark Watson, Cullen Jennings, Robert Sparks, Jonathan Rosenberg, Ben Campbell, Tom Gray and John Elwell for their comments.
作者は彼らのコメントについてアリソン・マンキン、Rohanマーイ、エリック・レスコラ、マーク・ワトソン、Cullenジョニングス、ロバート・スパークス、ジョナサン・ローゼンバーグ、ベン・キャンベル、トム・グレー、およびジョン・エルウェルに感謝したがっています。
Peterson Standards Track [Page 21] RFC 3323 Privacy Mechanism for SIP November 2002
ピーターソンStandardsは2002年11月に一口のためにRFC3323プライバシーメカニズムを追跡します[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Peterson Standards Track [Page 22]
ピーターソン標準化過程[22ページ]
一覧
スポンサーリンク
