Network Working Group J. Rosenberg
Request for Comments: 5079 Cisco
Category: Standards Track December 2007
Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）で拒否する匿名要求
Status of This 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose.
セッション開始プロトコル（SIP）のユーザーは匿名の電話をかけることが可能になります。しかし、このような呼び出しを受けたユーザーは、匿名であるため、それらを拒否する権利を持っています。 SIPは、コール拒否の理由は、コールが匿名だったということでした呼び出し側に指示する方法はありません。このような指示は、通話が匿名ずに再試行することを可能にするのに便利です。この仕様では、この目的のために新しいSIP応答コードを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 3
4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. 433 (Anonymity Disallowed) Definition . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
The Session Initiation Protocol (SIP) [RFC3261] allows for users to make anonymous calls. In RFC 3261, this is done by including a From header field whose display name has the value of "Anonymous". Greater levels of anonymity were subsequently defined in [RFC3323], which introduces the Privacy header field. The Privacy header field allows a requesting User Agent (UA) to ask for various levels of anonymity, including user level anonymity, header level anonymity, and session level anonymity. [RFC3325] additionally defined the P-Asserted-Identity header field, used to contain an asserted identity. RFC 3325 also defined the 'id' value for the Privacy header field, which is used to request the network to remove the P-Asserted-Identity header field.
ユーザーは匿名で電話をかけるために、セッション開始プロトコル（SIP）[RFC3261]はできます。 RFC 3261には、これは、その表示名「匿名」の値を有するヘッダフィールドからなどによって行われます。匿名性の高いレベルは、その後、プライバシーヘッダフィールドを導入する[RFC3323]で定義されました。プライバシーヘッダフィールドは、要求しているユーザエージェント（UA）は、ユーザ・レベルの匿名性、ヘッダレベルの匿名性、およびセッションレベルの匿名性を含む匿名の様々なレベルを要求することを可能にします。 [RFC3325]は、さらに、アサートされたアイデンティティを含有するために使用されるP-Asserted-Identityヘッダフィールドを、定義されました。 RFC 3325はまた、P-Asserted-Identityヘッダフィールドを除去するためにネットワークに要求するために使用されるプライバシーヘッダフィールドのための「ID」の値を定義しました。
Though users need to be able to make anonymous calls, users that receive such calls retain the right to reject the call because it is anonymous. SIP does not provide a response code that allows the User Agent Server (UAS), or a proxy acting on its behalf, to explicitly indicate that the request was rejected because it was anonymous. The closest response code is 403 (Forbidden), which doesn't convey a specific reason. While it is possible to include a reason phrase in a 403 response that indicates to the human user that the call was rejected because it was anonymous, that reason phrase is not useful for automata and cannot be interpreted by callers that speak a different language. An indication that can be understood by an automaton would allow for programmatic handling, including user interface prompts, or conversion to equivalent error codes in the Public Switched Telephone Network (PSTN) when the client is a gateway.
ユーザーは匿名で電話をかけることができるようにする必要がありますが、それは匿名であるため、このような呼び出しを受けるユーザーは、通話を拒否する権利を保有します。 SIPは、明示的にそれが匿名であったため、要求が拒否されたことを示すために、ユーザエージェントサーバ（UAS）、またはその代わりに行動する代理することができます応答コードを提供していません。最も近い応答コードは、特定の理由を伝えない403（禁止）、です。それは、匿名であったため、コールが拒否された人間のユーザに示す403応答理由フレーズを含めることは可能ですが、その理由のフレーズは、オートマトンのために有用ではありませんし、別の言語を話す発信者によって解釈することはできません。公共の場での等価エラーコードへのプログラムのユーザインターフェースプロンプトを含む取り扱い、または変換を可能にするオートマトンによって理解することができる指示は、クライアントがゲートウェイである場合交換電話網（PSTN）。
To remedy this, this specification defines the 433 (Anonymity Disallowed) response code.
この問題を解決するために、この仕様は433（匿名許可しない）応答コードを定義します。
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]に記載されているように解釈されます。
A server (generally acting on behalf of the called party, though this need not be the case) MAY generate a 433 (Anonymity Disallowed) response when it receives an anonymous request, and the server refuses to fulfill the request because the requestor is anonymous. A request SHOULD be considered anonymous when the identity of the originator of the request has been explicitly withheld by the originator. This occurs in any one of the following cases:
それは匿名の要求を受信し、要求者が匿名であるため、サーバーは要求を満たすことを拒否したときに（これある必要はないものの、一般的に、着信側のために行動する）サーバは433（匿名不許可）応答を生成してもよいです。要求の発信元の身元を明示的に発信者によって源泉徴収された場合、要求は、匿名を考慮すべきです。これは、次のいずれかの場合に発生します。
o The From header field contains a URI within the anonymous.invalid domain.
Fromヘッダフィールドoをanonymous.invalidドメイン内のURIを含みます。
o The From header field contains a display name whose value is either 'Anonymous' or 'anonymous'. Note that display names make a poor choice for indicating anonymity, since they are meant to be consumed by humans, not automata. Thus, language variations and even misspelling can cause an automaton to miss a hint in the display name. Despite these problems, a check on the display name is included here because RFC 3261 explicitly calls out the usage of the display name as a way to declare anonymity.
O Fromヘッダーフィールドは、その値がいずれかの「匿名」または「匿名」での表示名が含まれています。彼らは人間ではなく、オートマトンによって消費されることを意図されているので、その表示名は、匿名性を示すための貧弱な選択をすることに注意してください。このように、言語の変化、さらにはスペルミスが表示名にヒントを欠場するオートマトンを引き起こす可能性があります。 RFC 3261には、明示的に匿名性を宣言するための方法として、表示名の使用を呼び出しているため、これらの問題にもかかわらず、表示名のチェックはここに含まれています。
o The request contained a Privacy header field whose value indicates that the user wishes its identity withheld. Values meeting this criteria are 'id' [RFC3325] or 'user'.
O要求は、その値が、ユーザがそのアイデンティティが保留望むことを示すプライバシーヘッダフィールドを含んでいました。この基準を満たす値は、「ID」[RFC3325]または「ユーザー」です。
o The From header field contains a URI that has an explicit indication that it is anonymous. One such example of a mechanism that would meet this criteria is [coexistence]. This criteria is true even if the request has a validated Identity header field [RFC4474], which can be used in concert with anonymized From header fields.
Oヘッダフィールドから、匿名であることを明示的な指示を有するURIを含んでいます。この基準を満たすことになる機構のような一例は、[共存]です。リクエストヘッダフィールドから匿名化と協調して使用することができる検証Identityヘッダフィールド[RFC4474]を有していても、この基準が真です。
Lack of a network-asserted identity (such as the P-Asserted-Identity header field), in and of itself, SHOULD NOT be considered an indication of anonymity. Even though a Privacy header field value of 'id' will cause the removal of a network-asserted identity, there is no way to differentiate this case from one in which a network-asserted identity was not supported by the originating domain. As a consequence, a request without a network-asserted identity is considered anonymous only when there is some other indication of this, such as a From header field with a display name of 'Anonymous'.
（例えば、P-Asserted-Identityヘッダフィールドのような）ネットワークアサートアイデンティティの欠如は、それ自体が、匿名性の指標と考えるべきではありません。 「ID」のプライバシーヘッダフィールドの値は、ネットワークアサートアイデンティティの除去の原因となりますにもかかわらず、ネットワークアサートアイデンティティが元のドメインでサポートされていないされたものからこのケースを区別する方法はありません。このような「匿名」の表示名とFromヘッダーフィールドとして、この他のいくつかの兆候がある場合にのみその結果、ネットワークアサートアイデンティティのない要求は、匿名と考えられています。
In addition, requests where the identity of the requestor cannot be determined or validated, but it is not a consequence of an explicit action on the part of the requestor, are not considered anonymous. For example, if a request contains a non-anonymous From header field, along with the Identity and Identity-Info header fields [RFC4474],
また、要求者の身元が決定または検証が、それは、リクエスタの一部で明示的なアクションの結果ではないことができない要求は、匿名とは見なされません。例えば、要求は、IdentityとIdentity-Infoヘッダーフィールド[RFC4474]と共に、ヘッダフィールドからの非匿名で含まれている場合、
but the certificate could not be obtained from the reference in the Identity-Info header field, it is not considered an anonymous request, and the 433 response code SHOULD NOT be used.
しかし、証明書は、Identity-Infoヘッダフィールドの参照から得ることができなかった、それは、匿名要求考慮されていない、と433応答コードを使用しないでください。
A User Agent Client (UAC) receiving a 433 (Anonymity Disallowed) MUST NOT retry the request without anonymity unless it obtains confirmation from the user that this is desirable. Such confirmation could be obtained through the user interface, or by accessing user-defined policy. If the user has indicated that this is desirable, the UAC MAY retry the request without requesting anonymity. Note that if the UAC were to automatically retry the request without anonymity in the absence of an indication from the user that this treatment is desirable, then the user's expectations would not be met. Consequently, a user might think it had completed a call anonymously when it is not actually anonymous.
それは、これが望ましい、ユーザーからの確認を取得しない限り、ユーザエージェントクライアント（UAC）433（匿名不許可）を受けるには、匿名性のない要求を再試行してはなりません。そのような確認は、ユーザインタフェースを介して、またはユーザ定義のポリシーにアクセスすることによって得ることができました。ユーザーは、これが望ましいことが示されている場合、UACは、匿名性を要求せず、要求を再試行してもよい（MAY）。 UACは、自動的にこの治療が望まれることをユーザからの指示の不存在下で匿名なしに要求を再試行した場合、ユーザの期待を満たすことはないであろうことに留意されたいです。これにより、ユーザは、それが実際に匿名でないとき、それは匿名で通話を終了していたと思うかもしれません。
Receipt of a 433 response to a mid-dialog request SHOULD NOT cause the dialog to terminate, and SHOULD NOT cause the specific usage of that dialog to terminate [RFC5057].
半ば対話要求に433応答の受信は、ダイアログは終了しません。また、[RFC5057]を終了するには、そのダイアログの特定の使用が発生することはありません。
A UAC that does not understand or care about the specific semantics of the 433 response will treat it as a 400 response.
理解したり、433応答の特定のセマンティクスを気にしませんUACは400応答として扱います。
This response indicates that the server refused to fulfill the request because the requestor was anonymous. Its default reason phrase is "Anonymity Disallowed".
この応答は、要求者が匿名であるため、サーバーが要求を満たすことを拒否したことを示しています。デフォルトの理由フレーズは、「匿名許可しない」です。
This section registers a new SIP response code according to the procedures of RFC 3261.
このセクションでは、RFC 3261の手順に従って、新しいSIP応答コードを登録します。
RFC Number: RFC 5079
RFC番号：RFC 5079
Response Code Number: 433
応答コード番号：433
Default Reason Phrase: Anonymity Disallowed
デフォルトの理由フレーズ：匿名許可しません
The fact that a request was rejected because it was anonymous does reveal information about the called party -- that the called party does not accept anonymous calls. This information may or may not be sensitive. If it is, a UAS SHOULD reject the request with a 403 instead.
着信側が匿名のコールを受け入れないこと - それは匿名であったため、要求が拒否されたという事実は、被呼者についての情報を明らかにしません。この情報は、または敏感であってもなくてもよいです。もしそうであれば、UASは、代わりに403で要求を拒絶すべきです。
In the Public Switched Telephone Network (PSTN), the Anonymous Call Rejection (ACR) feature is commonly used to prevent unwanted calls from telemarketers (also known as spammers). Since telemarketers frequently withhold their identity, anonymous call rejection has the desired effect in many (but not all) cases. It is important to note that the response code described here is likely to be ineffective in blocking SIP-based spam. The reason is that a malicious caller can include a From header field and display name that is not anonymous, but is meaningless and invalid. Without a Privacy header field, such a request will not appear anonymous and thus not be blocked by an anonymity screening service. Dealing with SIP-based spam is not a simple problem. The reader is referred to [sipping-spam] for a discussion of the problem.
公衆交換電話網（PSTN）では、匿名コール除去（ACR）機能は、一般的に（もスパマーとして知られている）テレマーケティングから不要な呼び出しを防ぐために使用されます。テレマーケティングが頻繁に自分のアイデンティティを保留するので、匿名コール除去は、多くの（すべてではない）の場合、所望の効果を有します。ここで説明したレスポンスコードがSIPベースのスパムをブロックするのに効果がない可能性があることに注意することが重要です。その理由は、悪意のある呼び出し側がFromヘッダーフィールドが含まかつ匿名ではありませんが、無意味かつ無効である名前を表示することができるということです。プライバシーヘッダフィールドがなければ、そのような要求は匿名で表示されませんので、匿名のスクリーニングサービスによってブロックされることはありません。 SIPベースのスパムに対処する簡単な問題ではありません。読者は、問題の議論については、[スパムを飲み]と呼ばれます。
When anonymity services are being provided as a consequence of an anonymizer function acting as a back-to-back user agent (B2BUA) [RFC3323], and the anonymizer receives a 433 response, the anonymizer MUST NOT retry the request without anonymization unless it has been explicitly configured by the user to do so. In essence, the same rules that apply to a UA in processing of a 433 response apply to a network-based anonymization function, and for the same reasons.
匿名サービスは、バックツーバックユーザエージェント（B2BUA）[RFC3323]として作用アノニマイザ関数の結果として提供されており、アノニマイザ433応答を受信することがない限り、アノニマイザは、匿名化することなく、要求を再試行しない必要がある場合明示的にそうするようにユーザーが設定しました。本質的には、433応答の処理にUAと同じ規則は、ネットワークベースの匿名関数に、同じ理由で適用されます。
This document was motivated based on the requirements in [tispan-req], and has benefited from the concepts in [hautakorpi]. Thanks to Keith Drage, Paul Kyzivat, and John Elwell for their reviews of this document.
この文書では、[TISPAN-REQ]における要件に基づいて動機付けし、そして[hautakorpi]における概念から恩恵を受けています。このドキュメントの彼らのレビューのためのキース糖剤、ポールKyzivat、ジョンエルウェルに感謝します。
[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月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[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月。
[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月。
[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月。
[coexistence] Rosenberg, J., "Coexistence of P-Asserted-ID and SIP Identity", Work in Progress, June 2006.
[共生]ローゼンバーグ、J.、 "P-アサート-IDおよびSIPアイデンティティの共存"、進歩、2006年6月での作業。
[tispan-req] Jesske, R., "Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Institute", Work in Progress, July 2007.
[TISPAN-REQ] Jesske、R.、「欧州電気通信標準化協会の支援でセッション開始プロトコル（SIP）のための入力要件」、進歩、2007年7月の作業。
[hautakorpi] Hautakorpi, J. and G. Camarillo, "Extending the Session Initiation Protocol Reason Header with Warning Codes", Work in Progress, October 2005.
[hautakorpi] Hautakorpi、J.とG.カマリロ、「警告コードとのセッション開始プロトコルのReasonヘッダの拡張」、進歩、2005年10月に作業。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC in 5057, November 2007.
[RFC5057]スパークス、R.、5057で、RFC "セッション開始プロトコルの複数の対話用法"、2007年11月。
[sipping-spam] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol (SIP) and Spam", Work in Progress, August 2007.
[飲みスパム]ジェニングス、C.とJ.ローゼンバーグ、「セッション開始プロトコル（SIP）およびスパム」、進歩、2007年8月に作業。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサン・ローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。