[要約] RFC 5079は、SIPにおける匿名リクエストの拒否に関するガイドラインです。その目的は、セキュリティを向上させ、匿名リクエストによる悪意のある行動を防止することです。
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では、ディスプレイ名が「匿名」の値を持つヘッダーフィールドからのAを含めることによって行われます。その後、より大きなレベルの匿名性が[RFC3323]で定義され、プライバシーヘッダーフィールドが導入されました。プライバシーヘッダーフィールドにより、要求するユーザーエージェント（UA）は、ユーザーレベルの匿名性、ヘッダーレベルの匿名性、セッションレベルの匿名性など、さまざまなレベルの匿名性を要求できます。[RFC3325]は、主張されたアイデンティティを含むために使用されるP-Asserted-Identityヘッダーフィールドをさらに定義しました。RFC 3325は、プライバシーヘッダーフィールドの「ID」値も定義しました。これは、ネットワークにP-Asserted-Identityヘッダーフィールドを削除するために要求するために使用されます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
o From Headerフィールドには、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 Headerフィールドには、値が「匿名」または「匿名」のいずれかであるディスプレイ名が含まれています。ディスプレイ名は、匿名性を示すために不十分な選択をすることに注意してください。それらは、オートマトンではなく人間によって消費されることを意図しているためです。したがって、言語のバリエーションやスペルミスでさえ、オートマトンがディスプレイ名のヒントを見逃す可能性があります。これらの問題にもかかわらず、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 From Headerフィールドには、匿名であることを明示的に示すURIが含まれています。この基準を満たすメカニズムのそのような例の1つは[共存]です。この基準は、リクエストに検証済みのアイデンティティヘッダーフィールド[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」のプライバシーヘッダーフィールド値は、ネットワークに課されたアイデンティティの削除を引き起こしますが、このケースとネットワークastedされたアイデンティティが発信元のドメインによってサポートされていないケースを区別する方法はありません。結果として、「匿名」のディスプレイ名を持つヘッダーフィールドからの他の兆候がある場合にのみ、ネットワークastされたアイデンティティのないリクエストは匿名と見なされます。
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], 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.
さらに、要求者の身元を決定または検証できないが、要求者の部分での明示的なアクションの結果ではない場合、リクエストは匿名とは見なされません。たとえば、リクエストがヘッダーフィールドからの非匿名とIDおよびIDINFOヘッダーフィールド[RFC4474]を含むが、証明書はID-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は匿名を要求せずにリクエストを再試行することができます。この治療が望ましいというユーザーからの兆候がない場合、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ベースのスパムをブロックする際に効果がない可能性が高いことに注意することが重要です。その理由は、悪意のある発信者には、匿名ではないが無意味で無効なヘッダーフィールドとディスプレイ名を含めることができるためです。プライバシーヘッダーフィールドがなければ、そのようなリクエストは匿名ではないため、匿名のスクリーニングサービスによってブロックされません。SIPベースのスパムを扱うことは簡単な問題ではありません。読者は、問題の議論のために[Sipping-Spam]に紹介されます。
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]の概念の恩恵を受けています。Keith Drage、Paul Kyzivat、およびJohn Elwellに感謝します。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[coexistence] Rosenberg, J., "Coexistence of P-Asserted-ID and SIP Identity", Work in Progress, June 2006.
[共存] Rosenberg、J。、「P-Asserted-IDとSIP IDの共存」、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. Camarillo、「セッション開始プロトコル理由ヘッダーが警告コードを拡大する」、2005年10月、作業進行中。
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC in 5057, November 2007.
[RFC5057] Sparks、R。、「セッション開始プロトコルでの複数のダイアログ使用」、2007年11月5057年のRFC。
[sipping-spam] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol (SIP) and Spam", Work in Progress, August 2007.
[Sipping-Spam] Jennings、C。and J. Rosenberg、「セッション開始プロトコル（SIP）およびスパム」、2007年8月、進行中の作業。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。