[要約] RFC 5360は、SIPにおける同意ベースの通信のためのフレームワークを提供しています。このRFCの目的は、SIPセッションの開始と制御において、通信の同意を確保するためのガイドラインを提供することです。
Network Working Group J. Rosenberg
Request for Comments: 5360 Cisco Systems
Category: Standards Track G. Camarillo, Ed.
Ericsson
D. Willis
Unaffiliated
October 2008
A Framework for Consent-Based Communications 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
概要
SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP.
SIPは、リアルタイムオーディオ、ビデオ、テキスト、インスタントメッセージング、存在など、いくつかのサービスのコミュニケーションをサポートしています。現在の形式では、受信者の明示的な同意を必要とせずに、セッションの招待状、インスタントメッセージ、およびその他の要求をある当事者から別の当事者に配信することができます。そのような同意がなければ、SIPを増幅やDOS（サービス拒否）攻撃など、悪意のある目的に使用することが可能です。このドキュメントは、SIPでの同意ベースのコミュニケーションのフレームワークを特定します。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions and Terminology .....................................3
3. Relays and Translations .........................................4
4. Architecture ....................................................6
4.1. Permissions at a Relay .....................................6
4.2. Consenting Manipulations on a Relay's Translation Logic ....7
4.3. Store-and-Forward Servers ..................................8
4.4. Recipients Grant Permissions ...............................9
4.5. Entities Implementing This Framework .......................9
5. Framework Operations ............................................9
5.1. Amplification Avoidance ...................................11
5.1.1. Relay's Behavior ...................................12
5.2. Subscription to the Permission Status .....................12
5.2.1. Relay's Behavior ...................................13
5.3. Request for Permission ....................................13
5.3.1. Relay's Behavior ...................................13
5.4. Permission Document Structure .............................15
5.5. Permission Requested Notification .........................16
5.6. Permission Grant ..........................................17
5.6.1. Relay's Behavior ...................................17
5.6.1.1. SIP Identity ..............................17
5.6.1.2. P-Asserted-Identity .......................17
5.6.1.3. Return Routability ........................18
5.6.1.4. SIP Digest ................................19
5.7. Permission Granted Notification ...........................19
5.8. Permission Revocation .....................................19
5.9. Request-Contained URI Lists ...............................20
5.9.1. Relay's Behavior ...................................21
5.9.2. Definition of the 470 Response Code ................21
5.9.3. Definition of the Permission-Missing Header Field ..22
5.10. Registrations ............................................22
5.11. Relays Generating Traffic towards Recipients .............25
5.11.1. Relay's Behavior ..................................25
5.11.2. Definition of the Trigger-Consent Header Field ....25
6. IANA Considerations ............................................26
6.1. Registration of the 470 Response Code .....................26
6.2. Registration of the Trigger-Consent Header Field ..........26
6.3. Registration of the Permission-Missing Header Field .......26
6.4. Registration of the target-uri Header Field Parameter .....26
7. Security Considerations ........................................27
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
The Session Initiation Protocol (SIP) [RFC3261] supports communications for several services, including real-time audio, video, text, instant messaging, and presence. This communication is established by the transmission of various SIP requests (such as INVITE and MESSAGE [RFC3428]) from an initiator to the recipient with whom communication is desired. Although a recipient of such a SIP request can reject the request, and therefore decline the session, a network of SIP proxy servers will deliver a SIP request to its recipients without their explicit consent.
セッション開始プロトコル（SIP）[RFC3261]は、リアルタイムオーディオ、ビデオ、テキスト、インスタントメッセージング、存在など、いくつかのサービスの通信をサポートしています。このコミュニケーションは、イニシエーターから通信が望まれる受信者へのさまざまなSIPリクエスト（招待やメッセージ[RFC3428]など）の送信によって確立されます。このようなSIPリクエストの受信者はリクエストを拒否してセッションを拒否できますが、SIPプロキシサーバーのネットワークは、明示的な同意なしに受信者にSIPリクエストを配信します。
Receipt of these requests without explicit consent can cause a number of problems. These include amplification and DoS (Denial of Service) attacks. These problems are described in more detail in a companion requirements document [RFC4453].
明示的な同意なしにこれらのリクエストを受け取ると、多くの問題が発生する可能性があります。これらには、増幅とDOS（サービス拒否）攻撃が含まれます。これらの問題については、コンパニオン要件文書[RFC4453]で詳細に説明します。
This specification defines a basic framework for adding consent-based communication to SIP.
この仕様は、SIPに同意ベースのコミュニケーションを追加するための基本的なフレームワークを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Recipient URI: The Request-URI of an outgoing request sent by an entity (e.g., a user agent or a proxy). The sending of such request can have been the result of a translation operation.
受信者URI：エンティティから送信された発信リクエストのリクエスト-URI（例：ユーザーエージェントまたはプロキシ）。そのような要求の送信は、翻訳操作の結果である可能性があります。
Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs (i.e., recipient URIs), and delivers the request to those URIs.
リレー：プロキシ、B2BUA（連続したユーザーエージェント）、またはリクエストを受信するハイブリッドのSIPサーバーは、リクエスト-URIを1つ以上の次のホップURI（つまり、レシピエントURIS）に変換します。、そしてそれらのurisにリクエストを届けます。
Target URI: The Request-URI of an incoming request that arrives to a relay that will perform a translation operation.
ターゲットURI：翻訳操作を実行するリレーに到着する着信要求のリクエスト-URI。
Translation logic: The logic that defines a translation operation at a relay. This logic includes the translation's target and recipient URIs.
翻訳ロジック：リレーで翻訳操作を定義するロジック。このロジックには、翻訳のターゲットと受信者のURIが含まれます。
Translation operation: Operation by which a relay translates the Request-URI of an incoming request (i.e., the target URI) into one or more URIs (i.e., recipient URIs) that are used as the Request-URIs of one or more outgoing requests.
翻訳操作：リレーは、着信要求（つまり、ターゲットURI）のリクエストURIを1つ以上の発信リクエストのリクエストURIとして使用する1つまたは複数のURI（つまり、受信者URI）に変換する操作。
Relays play a key role in this framework. A relay is defined as any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs, and delivers the request to those URIs. The Request-URI of the incoming request is referred to as 'target URI' and the destination URIs of the outgoing requests are referred to as 'recipient URIs', as shown in Figure 1.
このフレームワークでは、リレーが重要な役割を果たします。リレーは、プロキシ、B2BUA（連続したユーザーエージェント）、またはリクエストを受信するハイブリッドなど、任意のSIPサーバーとして定義され、リクエスト-URIを1つまたは複数の次のホップURIに変換し、配信しますそれらのurisへの要求。着信要求のリクエスト-URIは「ターゲットURI」と呼ばれ、図1に示すように、発信リクエストの宛先URIは「受信者URIS」と呼ばれます。
+---------------+ recipient URI
| |---------------->
| |
target URI | Translation | [...]
-------------->| Operation |
| | recipient URI
| |---------------->
+---------------+
Figure 1: Translation Operation
図1：翻訳操作
Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates the Request-URI (target URI) into one or more additional URIs (recipient URIs). Through this translation operation, the relay can create outgoing requests to one or more additional recipient URIs, thus creating the consent problem.
したがって、リレーの重要な側面は翻訳の側面です。リレーがリクエストを受信すると、リクエスト-URI（ターゲットURI）を1つ以上の追加のURI（受信者URI）に変換します。この翻訳操作を通じて、リレーは1つ以上の追加の受信者URIに発信要求を作成し、同意の問題を作成できます。
The consent problem is created by two types of translations: translations based on local data and translations that involve amplifications.
同意の問題は、2種類の翻訳によって作成されます。ローカルデータと増幅を含む翻訳に基づく翻訳です。
Translation operations based on local policy or local data (such as registrations) are the vehicle by which a request is delivered directly to an endpoint, when it would not otherwise be possible to. In other words, if a spammer has the address of a user, 'sip:user@example.com', it cannot deliver a MESSAGE request to the UA (user agent) of that user without having access to the registration data that maps 'sip:user@example.com' to the user agent on which that user is present. Thus, it is the usage of this registration data, and more generally, the translation logic, that is expected to be authorized in order to prevent undesired communications. Of course, if the spammer knows the address of the user agent, it will be able to deliver requests directly to it.
ローカルポリシーまたはローカルデータ（登録など）に基づく翻訳操作は、それ以外の場合は不可能な場合、リクエストがエンドポイントに直接配信される手段です。言い換えれば、スパマーがユーザーのアドレス「sip：user@example.com」を持っている場合、マップする登録データにアクセスすることなく、そのユーザーのUA（ユーザーエージェント）にメッセージリクエストを配信することはできません。SIP：user@example.com 'そのユーザーが存在するユーザーエージェントに。したがって、望ましくない通信を防ぐために許可されることが期待されるのは、この登録データ、より一般的には翻訳ロジックの使用法です。もちろん、スパマーがユーザーエージェントのアドレスを知っている場合、リクエストを直接配信できます。
Translation operations that result in more than one recipient URI are a source of amplification. Servers that do not perform translations, such as outbound proxy servers, do not cause amplification. On the other hand, servers that perform translations (e.g., inbound proxies authoritatively responsible for a SIP domain) may cause amplification if the user can be reached at multiple endpoints (thereby resulting in multiple recipient URIs).
複数のレシピエントURIをもたらす翻訳操作は、増幅の原因です。アウトバウンドプロキシサーバーなどの翻訳を実行しないサーバーは、増幅を引き起こしません。一方、翻訳を実行するサーバー（たとえば、SIPドメインの権威ある責任を負うインバウンドプロキシ）は、複数のエンドポイントでユーザーに到達できる場合（それにより複数のレシピエントURIをもたらす）、増幅を引き起こす可能性があります。
Figure 2 shows a relay that performs translations. The user agent client in the figure sends a SIP request to a URI representing a resource in the domain 'example.com' (sip:resource@example.com). This request can pass through a local outbound proxy (not shown), but eventually arrives at a server authoritative for the domain 'example.com'. This server, which acts as a relay, performs a translation operation, translating the target URI into one or more recipient URIs, which can (but need not) belong to the domain 'example.com'. This relay can be, for instance, a proxy server or a URI-list service [RFC5363].
図2は、翻訳を実行するリレーを示しています。図のユーザーエージェントクライアントは、ドメイン「Example.com」（sip：resource@example.com）のリソースを表すURIにSIPリクエストを送信します。このリクエストは、ローカルアウトバウンドプロキシを通過できますが（表示されていません）、最終的にはドメインの「Example.com」に対して信頼できるサーバーに到着します。リレーとして機能するこのサーバーは、翻訳操作を実行し、ターゲットURIを1つまたは複数の受信者URIに変換します。このリレーは、たとえば、プロキシサーバーまたはURIリストサービス[RFC5363]です。
+-------+
| |
>| UA |
/ | |
/ +-------+
/
/
+-----------------------+ /
| | /
+-----+ | Relay | / +-------+
| | | |/ | |
| UA |------>| |-------->| Proxy |
| | |+---------------------+|\ | |
+-----+ || Translation || \ +-------+
|| Logic || \
|+---------------------+| \ [...]
+-----------------------+ \
\
\ +-------+
\ | |
>| B2BUA |
| |
+-------+
Figure 2: Relay Performing a Translation
図2：翻訳を実行するリレー
This framework allows potential recipients of a translation to agree to be actual recipients by giving the relay performing the translation permission to send them traffic.
このフレームワークにより、翻訳の潜在的な受信者は、トラフィックを送信するための翻訳許可を実行するリレーを提供することにより、実際の受信者になることに同意することができます。
Figure 3 shows the architectural elements of this framework. The manipulation of a relay's translation logic typically causes the relay to send a permission request, which in turn causes the recipient to grant or deny the relay permissions for the translation. Section 4.1 describes the role of permissions at a relay. Section 4.2 discusses the actions taken by a relay when its translation logic is manipulated by a client. Section 4.3 discusses store-and-forward servers and their functionality. Section 4.4 describes how potential recipients can grant a relay permissions to add them to the relay's translation logic. Section 4.5 discusses which entities need to implement this framework.
図3は、このフレームワークのアーキテクチャ要素を示しています。リレーの翻訳ロジックの操作により、通常、リレーは許可リクエストを送信します。これにより、受信者は翻訳のリレー許可を許可または拒否します。セクション4.1では、リレーでの権限の役割について説明します。セクション4.2では、翻訳ロジックがクライアントによって操作されたときにリレーが採用したアクションについて説明します。セクション4.3では、ストアアンドフォワードサーバーとその機能について説明します。セクション4.4では、潜在的な受信者がリレーのアクセス許可を付与してリレーの翻訳ロジックに追加する方法について説明します。セクション4.5では、このフレームワークを実装する必要があるエンティティについて説明します。
+-----------------------+ Permission +-------------+
| | Request | |
+--------+ | Relay |----------->| Store & Fwd |
| | | | | Server |
| Client | | | | |
| | |+-------+ +-----------+| +-------------+
+--------+ ||Transl.| |Permissions|| |
| ||Logic | | || Permission |
| |+-------+ +-----------+| Request |
| +-----------------------+ V
| ^ ^ +-------------+
| Manipulation | | Permission Grant | |
+---------------+ +-------------------| Recipient |
| |
+-------------+
Figure 3: Reference Architecture
図3：参照アーキテクチャ
Relays implementing this framework obtain and store permissions associated to their translation logic. These permissions indicate whether or not a particular recipient has agreed to receive traffic at any given time. Recipients that have not given the relay permission to send them traffic are simply ignored by the relay when performing a translation.
このフレームワークを実装するリレーは、翻訳ロジックに関連付けられた許可を取得および保存します。これらの許可は、特定の受信者がいつでもトラフィックを受信することに同意しているかどうかを示しています。リレーにトラフィックを送信する許可を与えていない受信者は、翻訳を実行するときにリレーによって単に無視されます。
In principle, permissions are valid as long as the context where they were granted is valid or until they are revoked. For example, the permissions obtained by a URI-list SIP service that distributes MESSAGE requests to a set of recipients will be valid as long as the URI-list SIP service exists or until the permissions are revoked.
原則として、許可が付与されたコンテキストが有効であるか、またはそれらが取り消されるまで有効である限り、権限は有効です。たとえば、メッセージ要求を受信者に配布するURIリストSIPサービスによって取得された権限は、URI-List SIPサービスが存在する限り、またはアクセス許可が取り消されるまで有効です。
Additionally, if a recipient is removed from a relay's translation logic, the relay SHOULD delete the permissions related to that recipient. For example, if the registration of a contact URI expires or is otherwise terminated, the registrar deletes the permissions related to that contact address.
さらに、受信者がリレーの翻訳ロジックから削除された場合、リレーはその受信者に関連する権限を削除する必要があります。たとえば、連絡先の登録がURIの有効期限が切れている場合、または終了した場合、レジストラはその連絡先アドレスに関連する権限を削除します。
It is also RECOMMENDED that relays request recipients to refresh their permissions periodically. If a recipient fails to refresh its permissions for a given period of time, the relay SHOULD delete the permissions related to that recipient.
また、リレイ要求レシピエントが定期的にアクセス許可を更新することをお勧めします。受信者が特定の期間の許可を更新できない場合、リレーはその受信者に関連するアクセス許可を削除する必要があります。
This framework does not provide any guidance for the values of the refreshment intervals because different applications can have different requirements to set those values. For example, a relay dealing with recipients that do not implement this framework may choose to use longer intervals between refreshes. The refresh process in such recipients has to be performed manually by their users (since the recipients do not implement this framework), and having too short refresh intervals may become too heavy a burden for those users.
このフレームワークは、異なるアプリケーションにこれらの値を設定するために異なる要件を持つ可能性があるため、リフレッシュ間隔の値のガイダンスを提供しません。たとえば、このフレームワークを実装していない受信者を扱うリレーは、リフレッシュ間でより長い間隔を使用することを選択できます。このような受信者の更新プロセスは、ユーザーが手動で実行する必要があります（受信者はこのフレームワークを実装していないため）。短すぎるリフレッシュ間隔を持つことは、それらのユーザーにとって重い負担になりすぎる場合があります。
This framework aims to ensure that any particular relay only performs translations towards destinations that have given the relay permission to perform such a translation. Consequently, when the translation logic of a relay is manipulated (e.g., a new recipient URI is added), the relay obtains permission from the new recipient in order to install the new translation logic. Relays ask recipients for permission using MESSAGE [RFC3428] requests.
このフレームワークの目的は、特定のリレーが、そのような翻訳を実行するためのリレーの許可を与えた目的地への翻訳のみを実行することを目的としています。その結果、リレーの翻訳ロジックが操作されると（たとえば、新しい受信者URIが追加されます）、リレーは新しい翻訳ロジックをインストールするために新しい受信者から許可を取得します。リレーメッセージ[RFC3428]リクエストを使用して、受信者に許可を求めます。
For example, the relay hosting the URI-list service at 'sip:friends@example.com' performs a translation from that target URI to a set of recipient URIs. When a client (e.g., the administrator of that URI-list service) adds 'bob@example.org' as a new recipient URI, the relay sends a MESSAGE request to 'sip:bob@example.org' asking whether or not it is OK to perform the translation from 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE request carries in its message body a permission document that describes the translation for which permissions are being requested and a human-readable part that also describes the translation. If the answer is positive, the new translation logic is installed at the relay. That is, the new recipient URI is added.
たとえば、「sip：friends@example.com」でURI-Listサービスをホストするリレーは、そのターゲットURIから受信者のURISのセットへの翻訳を実行します。クライアント（たとえば、そのURI-Listサービスの管理者）が新しい受信者URIとして「bob@example.org」を追加すると、リレーは「sip：bob@example.org」にメッセージ要求を送信します。「sip：friends@example.com」から「sip：bob@example.org」への翻訳を実行しても構いません。メッセージリクエストは、メッセージ本文に、許可が要求されている翻訳を説明する許可文書と、翻訳も説明する人間が読める部分を伝えます。答えが肯定的な場合、新しい翻訳ロジックがリレーにインストールされます。つまり、新しい受信者URIが追加されます。
The human-readable part is included so that user agents that do not understand permission documents can still process the request and display it in a sensible way to the user.
許可ドキュメントを理解していないユーザーエージェントがリクエストを処理し、ユーザーに賢明な方法で表示できるように、人間の読み取り可能な部分が含まれています。
The mechanism to be used to manipulate the translation logic of a particular relay depends on the relay. Two existing mechanisms to manipulate translation logic are XML Configuration Access Protocol (XCAP) [RFC4825] and REGISTER transactions.
特定のリレーの翻訳ロジックを操作するために使用されるメカニズムは、リレーに依存します。翻訳ロジックを操作する2つの既存のメカニズムは、XML構成アクセスプロトコル（XCAP）[RFC4825]と登録トランザクションです。
Section 5 uses a URI-list service whose translation logic is manipulated with XCAP as an example of a translation, in order to specify this framework. Section 5.10 discusses how to apply this framework to registrations, which are a different type of translation.
セクション5では、このフレームワークを指定するために、翻訳の例として、翻訳ロジックがXCAPで操作されるURIリストサービスを使用します。セクション5.10では、このフレームワークを登録に適用する方法について説明します。これは、異なるタイプの翻訳です。
In any case, relays implementing this framework SHOULD have a means to indicate that a particular recipient URI is in the states specified in [RFC5362] (i.e., pending, waiting, error, denied, or granted).
いずれにせよ、このフレームワークを実装するリレーには、特定の受信者のURIが[RFC5362]で指定されている州にあることを示す手段を持つ必要があります（つまり、保留中、待機、誤り、拒否、または付与）。
When a MESSAGE request with a permission document arrives to the recipient URI to which it was sent by the relay, the receiving user can grant or deny the permission needed to perform the translation. However, the receiving user may not be available when the MESSAGE request arrives, or it may have expressed preferences to block all incoming requests for a certain time period. In such cases, a store-and-forward server can act as a substitute for the user and buffer the incoming MESSAGE requests, which are subsequently delivered to the user when he or she is available again.
許可ドキュメントを使用したメッセージ要求が、リレーによって送信された受信者URIに到着すると、受信ユーザーは翻訳を実行するために必要な許可を許可または拒否できます。ただし、メッセージリクエストが到着したときに受信ユーザーが利用できない場合があります。または、特定の期間にわたってすべての着信要求をブロックする設定を表明した場合があります。そのような場合、ストアアンドフォワードサーバーはユーザーの代替として機能し、着信メッセージ要求をバッファーします。これは、再び利用可能になったときにユーザーに配信されます。
There are several mechanisms to implement store-and-forward message services (e.g., with an instant message to email gateway). Any of these mechanisms can be used between a user agent and its store-and-forward server as long as they agree on which mechanism to use. Therefore, this framework does not make any provision for the interface between user agents and their store-and-forward servers.
ストアアンドフォワードメッセージサービスを実装するメカニズムがいくつかあります（たとえば、電子メールゲートウェイへの即時メッセージがあります）。これらのメカニズムは、ユーザーエージェントとそのストアアンドフォワードサーバーの間で、使用するメカニズムに同意する限り使用できます。したがって、このフレームワークでは、ユーザーエージェントとそのストアアンドフォワードサーバーとの間のインターフェイスの規定はありません。
Note that the same store-and-forward message service can handle all incoming MESSAGE requests for a user while they are offline, not only those MESSAGE requests with a permission document in their bodies.
同じストアアンドフォワードメッセージサービスは、オフライン中にユーザーのすべての受信メッセージ要求を処理できることに注意してください。
Even though store-and-forward servers perform a useful function and they are expected to be deployed in most domains, some domains will not deploy them from the outset. However, user agents and relays in domains without store-and-forward servers can still use this consent framework.
ストアアンドフォワードサーバーは有用な機能を実行し、ほとんどのドメインに展開されると予想されていますが、一部のドメインは最初から展開しません。ただし、ストアアンドフォワードサーバーのないドメインのユーザーエージェントとリレーは、この同意フレームワークを使用することができます。
When a relay requests permissions from an offline user agent that does not have an associated store-and-forward server, the relay will obtain an error response indicating that its MESSAGE request could not be delivered. The client that attempted to add the offline user to the relay's translation logic will be notified about the error (e.g., using the Pending Additions event package [RFC5362]). This client MAY attempt to add the same user at a later point, hopefully when the user is online. Clients can discover whether or not a user is online by using a presence service, for instance.
リレーが関連するストアアンドフォワードサーバーを持たないオフラインユーザーエージェントにアクセス許可を要求すると、リレーはメッセージリクエストを配信できなかったことを示すエラー応答を取得します。オフラインユーザーをリレーの翻訳ロジックに追加しようとしたクライアントは、エラーについて通知されます（たとえば、保留中の追加イベントパッケージ[RFC5362]を使用して）。このクライアントは、ユーザーがオンラインであるときに、後の時点で同じユーザーを追加しようとする場合があります。たとえば、プレゼンスサービスを使用して、ユーザーがオンラインであるかどうかをクライアントが発見できます。
Permission documents generated by a relay include URIs that can be used by the recipient of the document to grant or deny the relay the permission described in the document. Relays always include SIP URIs and can include HTTP [RFC2616] URIs for this purpose. Consequently, recipients provide relays with permissions using SIP PUBLISH requests or HTTP GET requests.
リレーによって生成された許可文書には、ドキュメントの受信者がドキュメントに記載されている許可を許可または拒否するために使用できるURIが含まれています。リレーには常にSIP URIが含まれており、この目的のためにHTTP [RFC2616] URIを含めることができます。したがって、受信者は、SIPパブリッシュリクエストまたはHTTP Getリクエストを使用して、リレーをアクセス許可で提供します。
The goal of this framework is to keep relays from executing translations towards unwilling recipients. Therefore, all relays MUST implement this framework in order to avoid being used to perform attacks (e.g., amplification attacks).
このフレームワークの目標は、リレーが不本意な受信者への翻訳を実行しないようにすることです。したがって、すべてのリレーは、攻撃の実行に使用されないようにこのフレームワークを実装する必要があります（たとえば、増幅攻撃）。
This framework has been designed with backwards compatibility in mind so that legacy user agents (i.e., user agents that do not implement this framework) can act both as clients and recipients with an acceptable level of functionality. However, it is RECOMMENDED that user agents implement this framework, which includes supporting the Pending Additions event package specified in [RFC5362], the format for permission documents specified in [RFC5361], and the header fields and response code specified in this document, in order to achieve full functionality.
このフレームワークは、レガシーユーザーエージェント（つまり、このフレームワークを実装していないユーザーエージェント）が、許容レベルの機能性を持つクライアントと受信者の両方として機能できるように、逆方向の互換性を念頭に置いて設計されています。ただし、ユーザーエージェントは、[RFC5362]で指定された保留中追加の追加イベントパッケージ、[RFC5361]で指定された許可文書の形式、およびこのドキュメントで指定されたヘッダーフィールドと応答コードをサポートすることを含むこのフレームワークを実装することをお勧めします。完全な機能を達成するため。
The only requirement that this framework places on store-and-forward servers is that they need to be able to deliver encrypted and integrity-protected messages to their user agents, as discussed in Section 7. However, this is not a requirement specific to this framework but a general requirement for store-and-forward servers.
このフレームワークがストアアンドフォワードサーバーに配置する唯一の要件は、セクション7で説明するように、ユーザーエージェントに暗号化された整合性と保護されたメッセージを配信できることです。ただし、これはこれに固有の要件ではありません。フレームワークは、ストアアンドフォワードサーバーの一般的な要件です。
This section specifies this consent framework using an example of the prototypical call flow. The elements described in Section 4 (i.e., relays, translations, and store-and-forward servers) play an essential role in this call flow.
このセクションでは、プロトタイプのコールフローの例を使用して、この同意フレームワークを指定します。セクション4で説明されている要素（つまり、リレー、翻訳、ストアアンドフォワードサーバー）は、このコールフローで重要な役割を果たします。
Figure 4 shows the complete process to add a recipient URI ('sip:B@example.com') to the translation logic of a relay. User A attempts to add 'sip:B@example.com' as a new recipient URI to the translation logic of the relay (1). User A uses XCAP [RFC4825] and the XML (Extensible Markup Language) format for representing resource lists [RFC4826] to perform this addition. Since the relay does not have permission from 'sip:B@example.com' to perform translations towards that URI, the relay places 'sip:B@example.com' in the pending state, as specified in [RFC5362].
図4は、リレーの翻訳ロジックに受信者URI（ 'sip：b@example.com'）を追加する完全なプロセスを示しています。ユーザーAは、リレー（1）の翻訳ロジックに新しい受信者URIとして「sip：b@example.com」を追加しようとします。ユーザーAは、XCAP [RFC4825]とXML（拡張可能なマークアップ言語）形式を使用して、[RFC4826]を表現してこの追加を実行します。リレーは「sip：b@example.com」の許可を持っていないため、そのuriに翻訳を実行するために、[RFC5362]で指定されているように、保留状態のリレープレイス 'SIP：b@example.com」。
A@example.com Relay B's Store & Fwd B@example.com Server
a@example.comリレーBのストア＆fwd b@example.comサーバー
|(1) Add Recipient | |
| sip:B@example.com | |
|--------------->| | |
|(2) HTTP 202 (Accepted) | |
|<---------------| | |
| |(3) MESSAGE sip:B@example |
| | Permission Document |
| |--------------->| |
| |(4) 202 Accepted| |
| |<---------------| |
|(5) SUBSCRIBE | | |
| Event: pending-additions | |
|--------------->| | |
|(6) 200 OK | | |
|<---------------| | |
|(7) NOTIFY | | |
|<---------------| | |
|(8) 200 OK | | |
|--------------->| | |
| | | |User B goes
| | | | online
| | |(9) Request for |
| | | stored messages
| | |<---------------|
| | |(10) Delivery of|
| | | stored messages
| | |--------------->|
| |(11) PUBLISH uri-up |
| |<--------------------------------|
| |(12) 200 OK | |
| |-------------------------------->|
|(13) NOTIFY | | |
|<---------------| | |
|(14) 200 OK | | |
|--------------->| | |
Figure 4: Prototypical Call Flow
図4：プロトタイプのコールフロー
Once 'sip:B@example.com' is in the pending state, the relay needs to ask user B for permission by sending a MESSAGE request to 'sip:B@example.com'. However, the relay needs to ensure that it is not used as an amplifier to launch amplification attacks.
「sip：b@example.com」が保留中の状態にあると、リレーは「sip：b@example.com」にメッセージリクエストを送信することにより、ユーザーBに許可を求める必要があります。ただし、リレーは、増幅攻撃を起動するためのアンプとして使用されないことを確認する必要があります。
In such an attack, the attacker would add a large number of recipient URIs to the translation logic of a relay. The relay would then send a MESSAGE request to each of those recipient URIs. The bandwidth generated by the relay would be much higher than the bandwidth used by the attacker to add those recipient URIs to the translation logic of the relay.
このような攻撃では、攻撃者はリレーの翻訳ロジックに多数のレシピエントURIを追加します。リレーは、それらの受信者の各urisにメッセージ要求を送信します。リレーによって生成された帯域幅は、攻撃者がそれらの受信者をリレーの翻訳ロジックに追加するために使用する帯域幅よりもはるかに高くなります。
This framework uses a credit-based authorization mechanism to avoid the attack just described. It requires users adding new recipient URIs to a translation to generate an amount of bandwidth that is comparable to the bandwidth the relay will generate when sending MESSAGE requests towards those recipient URIs. When XCAP is used, this requirement is met by not allowing clients to add more than one URI per HTTP transaction. When a REGISTER transaction is used, this requirement is met by not allowing clients to register more than one contact per REGISTER transaction.
このフレームワークは、クレジットベースの承認メカニズムを使用して、今説明した攻撃を回避します。ユーザーは、新しい受信者URIを翻訳に追加する必要があります。これは、受信者のURIにメッセージ要求を送信するときにリレーが生成する帯域幅に匹敵する帯域幅を生成する必要があります。XCAPを使用すると、この要件は、クライアントがHTTPトランザクションごとに複数のURIを追加できるようにすることで満たされます。レジスタトランザクションが使用されると、この要件は、クライアントがレジスタトランザクションごとに複数の連絡先を登録できないようにして満たされます。
Relays implementing this framework MUST NOT allow clients to add more than one recipient URI per transaction. If a client using XCAP attempts to add more than one recipient URI in a single HTTP transaction, the XCAP server SHOULD return an HTTP 409 (Conflict) response. The XCAP server SHOULD describe the reason for the refusal in an XML body using the <constraint-failure> element, as described in [RFC4825]. If a client attempts to register more than one contact in a single REGISTER transaction, the registrar SHOULD return a SIP 403 response and explain the reason for the refusal in its reason phrase (e.g., maximum one contact per registration).
このフレームワークを実装するリレーでは、クライアントがトランザクションごとに複数の受信者URIを追加できるようにしてはなりません。XCAPを使用しているクライアントが、単一のHTTPトランザクションに複数の受信者URIを追加しようとする場合、XCAPサーバーはHTTP 409（競合）応答を返す必要があります。XCAPサーバーは、[RFC4825]に記載されているように、<Constraint-Failure>要素を使用してXMLボディの拒否の理由を説明する必要があります。クライアントが単一のレジスタトランザクションで複数の連絡先を登録しようとする場合、レジストラはSIP 403応答を返し、その理由フレーズの拒否の理由を説明する必要があります（たとえば、登録ごとに最大1つの連絡先）。
Clients need a way to be informed about the status of the operations they requested. Otherwise, users can be waiting for an operation to succeed when it has actually already failed. In particular, if the target of the request for consent was not reachable and did not have an associated store-and-forward server, the client needs to know to retry the request later. The Pending Additions SIP event package [RFC5362] is a way to provide clients with that information.
クライアントは、要求した運用のステータスについて通知する方法が必要です。それ以外の場合、ユーザーは実際に既に失敗したときに操作が成功するのを待つことができます。特に、同意要求のターゲットが到達できず、関連するストアアンドフォワードサーバーを持っていなかった場合、クライアントは後でリクエストを再試行するために知る必要があります。保留中の追加のSIPイベントパッケージ[RFC5362]は、クライアントにその情報を提供する方法です。
Clients can use the Pending Additions SIP event package to be informed about the status of the operations they requested. That is, the client will be informed when an operation (e.g., the addition of a recipient URI to a relay's translation logic) is authorized (and thus executed) or rejected. Clients use the target URI of the SIP translation being manipulated to subscribe to the 'pending-additions' event package.
クライアントは、保留中の追加のSIPイベントパッケージを使用して、要求した操作のステータスについて通知することができます。つまり、クライアントは、操作（例えば、リレーの翻訳ロジックへの受信者のURIの追加）が承認（したがって実行されます）または拒否されるときに通知されます。クライアントは、操作されているSIP翻訳のターゲットURIを使用して、「保留中の」イベントパッケージを購読します。
In our example, after receiving the response from the relay (2), user A subscribes to the Pending Additions event package at the relay (5). This subscription keeps user A informed about the status of the permissions (e.g., granted or denied) the relay will obtain.
この例では、リレー（2）から応答を受信した後、ユーザーAはリレー（5）で保留中の追加イベントパッケージを購読します。このサブスクリプションにより、ユーザーは、リレーが取得する権限のステータス（付与または拒否など）について通知されます。
Relays SHOULD support the Pending Additions SIP event package specified in [RFC5362].
リレーは、[RFC5362]で指定された保留中の追加のSIPイベントパッケージをサポートする必要があります。
A relay requests permissions from potential recipients to add them to its translation logic using MESSAGE requests. In our example, on receiving the request to add user B to the translation logic of the relay (1), the relay generates a MESSAGE request (3) towards 'sip:B@example.com'. This MESSAGE request carries a permission document, which describes the translation that needs to be authorized and carries a set of URIs to be used by the recipient to grant or to deny the relay permission to perform that translation. Since user B is offline, the MESSAGE request will be buffered by user B's store-and-forward server. User B will later go online and authorize the translation by using one of those URIs, as described in Section 5.6. The MESSAGE request also carries a body part that contains the same information as the permission document but in a human-readable format.
リレーは、潜在的な受信者から許可を要求し、メッセージ要求を使用して翻訳ロジックに追加します。この例では、リレー（1）の翻訳ロジックにユーザーBを追加するリクエストを受信すると、リレーは「sip：b@example.com」に向けてメッセージ要求（3）を生成します。このメッセージリクエストには、許可ドキュメントが付属しています。これは、許可される必要がある翻訳を説明し、受信者がその翻訳を実行するためのリレーの許可を許可または拒否するために使用されるURIのセットを運ぶことができます。ユーザーBはオフラインであるため、メッセージリクエストはユーザーBのストアアンドフォワードサーバーによってバッファリングされます。セクション5.6で説明されているように、ユーザーBは後でオンラインになり、それらのURIのいずれかを使用して翻訳を承認します。メッセージリクエストには、許可ドキュメントと同じ情報を含むが、人間が読み取る形式であるボディパーツも搭載されています。
When user B uses one of the URIs in the permission document to grant or deny permissions, the relay needs to make sure that it was actually user B using that URI, and not an attacker. The relay can use any of the methods described in Section 5.6 to authenticate the permission document.
ユーザーBが許可文書でURIの1つを使用して許可を付与または拒否する場合、リレーは、攻撃者ではなく、そのURIを使用して実際にユーザーBであることを確認する必要があります。リレーは、セクション5.6で説明されている方法のいずれかを使用して、許可ドキュメントを認証できます。
Relays that implement this framework MUST obtain permissions from potential recipients before adding them to their translation logic. Relays request permissions from potential recipients using MESSAGE requests.
このフレームワークを実装するリレーは、翻訳ロジックに追加する前に、潜在的な受信者からアクセス許可を取得する必要があります。メッセージリクエストを使用して、潜在的な受信者からのリクエスト要求許可。
Section 5.6 describes the methods a relay can use to authenticate those recipients giving the relay permission to perform a particular translation. These methods are SIP identity [RFC4474], P-Asserted-Identity [RFC3325], a return routability test, or SIP digest. Relays that use the method consisting of a return routability test have to send their MESSAGE requests to a SIPS URI, as specified in Section 5.6.
セクション5.6では、リレーが特定の翻訳を実行するためのリレーの許可を与える受信者を認証するためにリレーが使用できる方法について説明します。これらの方法は、SIPアイデンティティ[RFC4474]、P asserted-Identity [RFC3325]、リターンルー上のテスト、またはSIPダイジェストです。リターンルーティング可能性テストで構成されるメソッドを使用するリレーは、セクション5.6で指定されているように、メッセージリクエストをSIPS URIに送信する必要があります。
MESSAGE requests sent to request permissions MUST include a permission document and SHOULD include a human-readable part in their bodies. The human-readable part contains the same information as the permission document (but in a human-readable format), including the URIs to grant and deny permissions. User agents that do not understand permission documents can still process the request and display it in a sensible way to the user, as they would display any other instant message. This way, even if the user agent does not implement this framework, the (human) user will be able to manually click on the correct URI in order to grant or deny permissions. The following is an example of a MESSAGE request that carries a human-readable part and a permission document, which follows the format specified in [RFC5361], in its body. Not all header fields are shown for simplicity reasons.
要求許可に送信されたメッセージ要求には、許可ドキュメントを含める必要があり、人間の読み取り可能な部品を身体に含める必要があります。人間読み取り可能な部分には、許可を付与および拒否するURIを含む、許可文書（ただし、人間が読める形式）と同じ情報が含まれています。許可ドキュメントを理解していないユーザーエージェントは、リクエストを処理し、他のインスタントメッセージを表示するため、賢明な方法でユーザーに表示できます。このように、ユーザーエージェントがこのフレームワークを実装していなくても、（人間の）ユーザーは、許可を付与または拒否するために、正しいURIを手動でクリックすることができます。以下は、人間の読み取り可能な部分と、[RFC5361]で指定された形式のボディ内で指定されたフォーマットに従う許可文書を伝えるメッセージリクエストの例です。すべてのヘッダーフィールドが単純な理由で表示されるわけではありません。
MESSAGE sip:bob@example.org SIP/2.0
From: <sip:alices-friends@example.com>;tag=12345678
To: <sip:bob@example.org>
Content-Type: multipart/mixed;boundary="boundary1"
--boundary1
Content-Type: text/plain
If you consent to receive traffic sent to
<sip:alices-friends@example.com>, please use one of the following
URIs: <sips:grant-1awdch5Fasddfce34@example.com> or
<https://example.com/grant-1awdch5Fasddfce34>. Otherwise, use one of
the following URIs: <sips:deny-23rCsdfgvdT5sdfgye@example.com> or
<https://example.com/deny-23rCsdfgvdT5sdfgye>.
--boundary1
Content-Type: application/auth-policy+xml
<?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset
xmlns="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cp:rule id="f1">
<cp:conditions>
<cp:identity>
<cp:many/>
</cp:identity>
<recipient>
<cp:one id="sip:bob@example.org"/>
</recipient>
<target>
<cp:one id="sip:alices-friends@example.com"/>
</target>
</cp:conditions>
<cp:actions>
<trans-handling
perm-uri="sips:grant-1awdch5Fasddfce34@example.com">
grant</trans-handling>
<trans-handling
perm-uri="https://example.com/grant-1awdch5Fasddfce34">
grant</trans-handling>
<trans-handling
perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com">
deny</trans-handling>
<trans-handling
perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye">
deny</trans-handling>
</cp:actions>
<cp:transformations/>
</cp:rule>
</cp:ruleset>
--boundary1--
A permission document is the representation (e.g., encoded in XML) of a permission. A permission document contains several pieces of data:
許可文書は、許可の表現（XMLでエンコードされた例：XML）です。許可ドキュメントには、いくつかのデータが含まれています。
Identity of the Sender: A URI representing the identity of the sender for whom permissions are granted.
送信者の身元：権限が付与される送信者の身元を表すURI。
Identity of the Original Recipient: A URI representing the identity of the original recipient, which is used as the input for the translation operation. This is also called the target URI.
元の受信者の身元：翻訳操作の入力として使用される元の受信者の識別を表すURI。これはターゲットURIとも呼ばれます。
Identity of the Final Recipient: A URI representing the result of the translation. The permission grants ability for the sender to send requests to the target URI and for a relay receiving those requests to forward them to this URI. This is also called the recipient URI.
最終受信者の身元：翻訳の結果を表すURI。許可は、送信者がターゲットURIにリクエストを送信し、それらのリクエストを受け取るリレーがこのURIに転送するリレーを付与します。これは、受信者URIとも呼ばれます。
URIs to Grant Permission: URIs that recipients can use to grant the relay permission to perform the translation described in the document. Relays MUST support the use of SIP and SIPS URIs in permission documents and MAY support the use of HTTP and HTTPS URIs.
許可を付与するためのuris：受信者は、ドキュメントに記載されている翻訳を実行するためのリレー許可を付与するために使用できるuris。リレーは、許可文書でSIPおよびSIP URIの使用をサポートし、HTTPおよびHTTPS URIの使用をサポートする必要があります。
URIs to Deny Permission: URIs that recipients can use to deny the relay permission to perform the translation described in the document. Relays MUST support the use of SIP and SIPS URIs in permission documents and MAY support the use of HTTP and HTTPS URIs.
許可を拒否するウリス：受信者は、ドキュメントに記載されている翻訳を実行するためのリレーの許可を拒否するために使用できるURIS。リレーは、許可文書でSIPおよびSIP URIの使用をサポートし、HTTPおよびHTTPS URIの使用をサポートする必要があります。
Permission documents can contain wildcards. For example, a permission document can request permission for any relay to forward requests coming from a particular sender to a particular recipient. Such a permission document would apply to any target URI. That is, the field containing the identity of the original recipient would match any URI. However, the recipient URI MUST NOT be wildcarded.
許可文書にはワイルドカードを含めることができます。たとえば、許可ドキュメントは、特定の送信者から特定の受信者への転送要求へのリレーの許可を要求できます。このような許可文書は、任意のターゲットURIに適用されます。つまり、元の受信者の身元を含むフィールドは、任意のURIと一致します。ただし、受信者のURIはワイルドカードであってはなりません。
Entities implementing this framework MUST support the format for permission documents defined in [RFC5361] and MAY support other formats.
このフレームワークを実装するエンティティは、[RFC5361]で定義されている許可文書の形式をサポートする必要があり、他の形式をサポートする場合があります。
In our example, the permission document in the MESSAGE request (3) sent by the relay contains the following values:
この例では、リレーで送信されたメッセージ要求（3）の許可文書には、次の値が含まれています。
Identity of the Sender: Any sender
送信者の身元：送信者
Identity of the Original Recipient: sip:friends@example.com
Identity of the Final Recipient: sip:B@example.com
URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com
URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34
許可を与えるURI：https：//example.com/grant-1awdch5fasddfce34
URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com
URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye
許可を拒否するURI：https：//example.com/deny-23rcsdfgvdt5sdfgye
It is expected that the Sender field often contains a wildcard. However, scenarios involving request-contained URI lists, such as the one described in Section 5.9, can require permission documents that apply to a specific sender. In cases where the identity of the sender matters, relays MUST authenticate senders.
送信者フィールドにはしばしばワイルドカードが含まれることが予想されます。ただし、セクション5.9で説明されているようなリクエストが含むURIリストを含むシナリオには、特定の送信者に適用される許可ドキュメントが必要になる場合があります。送信者の身元が重要な場合、リレーは送信者を認証する必要があります。
On receiving the MESSAGE request (3), user B's store-and-forward server stores it because user B is offline at that point. When user B goes online, user B fetches all the requests its store-and-forward server has stored (9).
メッセージリクエスト（3）を受信すると、ユーザーBがその時点でオフラインになっているため、ユーザーBのストアアンドフォワードサーバーが保存されます。ユーザーBがオンラインになると、ユーザーBはすべてのリクエストを取得し、そのストアアンドフォワードサーバーが保存しています（9）。
A recipient gives a relay permission to execute the translation described in a permission document by sending a SIP PUBLISH or an HTTP GET request to one of the URIs to grant permissions contained in the document. Similarly, a recipient denies a relay permission to execute the translation described in a permission document by sending a SIP PUBLISH or an HTTP GET request to one of the URIs to deny permissions contained in the document. Requests to grant or deny permissions contain an empty body.
受信者は、SIPパブリッシュまたはHTTP GetリクエストをURISのいずれかに送信して、ドキュメントに含まれる許可を付与することにより、許可ドキュメントに記載されている翻訳を実行するリレーの許可を与えます。同様に、受信者は、SIPパブリッシュまたはHTTP GetリクエストをURISのいずれかに送信して、ドキュメントに含まれる権限を拒否することにより、許可ドキュメントに記載されている翻訳を実行するリレーの許可を拒否します。許可を付与または拒否するリクエストには、空のボディが含まれています。
In our example, user B obtains the permission document (10) that was received earlier by its store-and-forward server in the MESSAGE request (3). User B authorizes the translation described in the permission document received by sending a PUBLISH request (11) to the SIP URI to grant permissions contained in the permission document.
この例では、ユーザーBは、メッセージリクエスト（3）でストアアンドフォワードサーバーによって以前に受信された許可ドキュメント（10）を取得します。ユーザーBは、公開要求（11）をSIP URIに送信することで受信した許可文書で説明されている翻訳を許可して、許可文書に含まれる許可を付与します。
Relays MUST ensure that the SIP PUBLISH or the HTTP GET request received was generated by the recipient of the translation and not by an attacker. Relays can use four methods to authenticate those requests: SIP identity, P-Asserted-Identity [RFC3325], a return routability test, or SIP digest. While return routability tests can be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP identity, P-Asserted-Identity, and SIP digest can only be used to authenticate SIP PUBLISH requests. SIP digest can only be used to authenticate recipients that share a secret with the relay (e.g., recipients that are in the same domain as the relay).
リレーは、攻撃者ではなく、翻訳の受信者によってSIPパブリッシュまたはHTTP GETリクエストが受信されたことを確認する必要があります。リレーは4つの方法を使用して、それらのリクエストを認証できます。SIPアイデンティティ、Pアサート付きアイデンティティ[RFC3325]、リターンルー上のテスト、またはSIPダイジェスト。RETURN ROUDABILTYテストは、SIPパブリッシュとHTTP Get Requests、SIP ID、P-Asserted-Identity、SIP Digestの両方を認証するために使用できます。SIPパブリッシュリクエストの認証にのみ使用できます。SIP Digestは、秘密をリレー（例えば、リレーと同じドメインにある受信者）と共有する受信者を認証するためにのみ使用できます。
The SIP identity [RFC4474] mechanism can be used to authenticate the sender of a PUBLISH request. The relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further.
SIP ID [RFC4474]メカニズムを使用して、公開リクエストの送信者を認証できます。リレーは、公開要求のオリジネーターが許可文書にある受信者URIの所有者であることを確認する必要があります。それ以外の場合、パブリッシュリクエストは401（不正な）応答で応答する必要があり、さらに処理してはなりません。
The P-Asserted-Identity [RFC3325] mechanism can also be used to authenticate the sender of a PUBLISH request. However, as discussed in [RFC3325], this mechanism is intended to be used only within networks of trusted SIP servers. That is, the use of this mechanism is only applicable inside an administrative domain with previously agreed-upon policies.
P-Asserted-Identity [RFC3325]メカニズムを使用して、公開リクエストの送信者を認証することもできます。ただし、[RFC3325]で説明したように、このメカニズムは、信頼できるSIPサーバーのネットワーク内でのみ使用することを目的としています。つまり、このメカニズムの使用は、以前に合意されたポリシーを備えた管理ドメイン内でのみ適用されます。
The relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further.
リレーは、公開要求のオリジネーターが許可文書にある受信者URIの所有者であることを確認する必要があります。それ以外の場合、パブリッシュリクエストは401（不正な）応答で応答する必要があり、さらに処理してはなりません。
SIP identity provides a good authentication mechanism for incoming PUBLISH requests. Nevertheless, SIP identity is not widely available on the public Internet yet. That is why an authentication mechanism that can already be used at this point is needed.
SIP IDは、発行リクエストを着信するための優れた認証メカニズムを提供します。それにもかかわらず、SIP IDはまだパブリックインターネットでは広く利用できません。そのため、この時点ですでに使用できる認証メカニズムが必要です。
Return routability tests do not provide the same level of security as SIP identity, but they provide a better-than-nothing security level in architectures where the SIP identity mechanism is not available (e.g., the current Internet). The relay generates an unguessable URI (i.e., with a cryptographically random user part) and places it in the permission document in the MESSAGE request (3). The recipient needs to send a SIP PUBLISH request or an HTTP GET request to that URI. Any incoming request sent to that URI SHOULD be considered authenticated by the relay.
Returbability Testsは、SIP IDと同じレベルのセキュリティを提供しませんが、SIP IDメカニズムが利用できないアーキテクチャでは、より良いセキュリティレベルを提供します（例：現在のインターネット）。リレーは、非適切なURI（つまり、暗号化的にランダムなユーザーパーツを使用）を生成し、メッセージ要求（3）に許可文書に配置します。受信者は、SIPパブリックリクエストまたはHTTP Get RequestをそのURIに送信する必要があります。そのURIに送信された受信リクエストは、リレーによって認証されたと見なされる必要があります。
Note that the return routability method is the only one that allows the use of HTTP URIs in permission documents. The other methods require the use of SIP URIs.
Return Routabilityメソッドは、許可ドキュメントでHTTP URIを使用できる唯一の方法であることに注意してください。他の方法では、SIP URIの使用が必要です。
Relays using a return routability test to perform this authentication MUST send the MESSAGE request with the permission document to a SIPS URI. This ensures that attackers do not get access to the (unguessable) URI. Thus, the only user able to use the (unguessable) URI is the receiver of the MESSAGE request. Similarly, permission documents sent by relays using a return routability test MUST only contain secure URIs (i.e., SIPS and HTTPS) to grant and deny permissions. A part of these URIs (e.g., the user part of a SIPS URI) MUST be cryptographically random with at least 32 bits of randomness.
この認証を実行するためにリターンルーチャビリティテストを使用したリレーは、許可ドキュメントを使用してメッセージリクエストをSIPS URIに送信する必要があります。これにより、攻撃者が（装備できない）URIにアクセスできないことが保証されます。したがって、（装備できない）URIを使用できる唯一のユーザーは、メッセージ要求の受信者です。同様に、返品ルー上のテストを使用してリレーから送信された許可文書は、許可を付与および拒否するために安全なURI（つまり、SIPおよびHTTPS）のみを含む必要があります。これらのURIの一部（たとえば、SIPS URIのユーザー部分）は、少なくとも32ビットのランダム性で暗号化的にランダムでなければなりません。
Relays can transition from return routability tests to SIP identity by simply requiring the use of SIP identity for incoming PUBLISH requests. That is, such a relay would reject PUBLISH requests that did not use SIP identity.
リレーは、出版リクエストのためにSIP IDを使用するだけで、RETURNルー上のルー上のテストからSIP IDに移行できます。つまり、そのようなリレーは、SIP IDを使用していない公開要求を拒否します。
The SIP digest mechanism can be used to authenticate the sender of a PUBLISH request as long as that sender shares a secret with the relay. The relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further.
SIPダイジェストメカニズムは、その送信者がリレーと秘密を共有する限り、公開要求の送信者を認証するために使用できます。リレーは、公開要求のオリジネーターが許可文書にある受信者URIの所有者であることを確認する必要があります。それ以外の場合、パブリッシュリクエストは401（不正な）応答で応答する必要があり、さらに処理してはなりません。
On receiving the PUBLISH request (11), the relay sends a NOTIFY request (13) to inform user A that the permission for the translation has been received and that the translation logic at the relay has been updated. That is, 'sip:B@example.com' has been added as a recipient URI.
公開要求（11）を受信すると、リレーは通知要求（13）を送信して、翻訳の許可が受信され、リレーの翻訳ロジックが更新されたことをユーザーAに通知します。つまり、「sip：b@example.com」が受信者URIとして追加されました。
At any time, if a recipient wants to revoke any permission, it uses the URI it received in the permission document to deny the permissions it previously granted. If a recipient loses this URI for some reason, it needs to wait until it receives a new request produced by the translation. Such a request will contain a Trigger-Consent header field with a URI. That Trigger-Consent header field will have a target-uri header field parameter identifying the target URI of the translation. The recipient needs to send a PUBLISH request with an empty body to the URI in the Trigger-Consent header field in order to receive a MESSAGE request from the relay. Such a MESSAGE request will contain a permission document with a URI to revoke the permission that was previously granted.
いつでも、受信者が許可を取り消したい場合、許可文書で受け取ったURIを使用して、以前に付与した許可を拒否します。受信者が何らかの理由でこのURIを失った場合、翻訳によって作成された新しいリクエストを受信するまで待つ必要があります。このようなリクエストには、URIを備えたトリガーコンセントヘッダーフィールドが含まれます。そのトリガーコンセントヘッダーフィールドには、翻訳のターゲットURIを識別するターゲットURIヘッダーフィールドパラメーターがあります。受信者は、リレーからメッセージリクエストを受信するために、トリガーコンセントヘッダーフィールドのURIに空のボディを持つ公開リクエストを送信する必要があります。このようなメッセージリクエストには、以前に付与された許可を取り消すために、URIを使用した許可文書が含まれます。
Figure 5 shows an example of how a user that lost the URI to revoke permissions at a relay can obtain a new URI using the Trigger-Consent header field of an incoming request. The user rejects an incoming INVITE (1) request, which contains a Trigger-Consent header field. Using the URI in that header field, the user sends a PUBLISH request (4) to the relay. On receiving the PUBLISH request (4), the relay generates a MESSAGE request (6) towards the user. Finally, the user revokes the permissions by sending a PUBLISH request (8) to the relay.
図5は、リレーで許可を取り消すためにURIを失ったユーザーが、着信要求のトリガーコンセントヘッダーフィールドを使用して新しいURIを取得する方法の例を示しています。ユーザーは、トリガーコンセントヘッダーフィールドを含む着信招待状（1）リクエストを拒否します。そのヘッダーフィールドでURIを使用して、ユーザーはリレーにパブリッシュリクエスト（4）を送信します。パブリッシュリクエスト（4）を受信すると、リレーはユーザーに対してメッセージリクエスト（6）を生成します。最後に、ユーザーは公開要求（8）をリレーに送信することにより、権限を取り消します。
Relay B@example.com
|(1) INVITE |
| Trigger-Consent: sip:123@relay.example.com
| ;target-uri="sip:friends@relay.example.com"
|---------------------------->|
|(2) 603 Decline |
|<----------------------------|
|(3) ACK |
|---------------------------->|
|(4) PUBLISH sip:123@relay.example.com
|<----------------------------|
|(5) 200 OK |
|---------------------------->|
|(6) MESSAGE sip:B@example |
| Permission Document |
|---------------------------->|
|(7) 200 OK |
|<----------------------------|
|(8) PUBLISH uri-deny |
|<----------------------------|
|(9) 200 OK |
|---------------------------->|
Figure 5: Permission Revocation
図5：許可の取り消し
In the scenarios described so far, a user adds recipient URIs to the translation logic of a relay. However, the relay does not perform translations towards those recipient URIs until permissions are obtained.
これまでに説明されているシナリオでは、ユーザーが受信者をリレーの翻訳ロジックに追加します。ただし、リレーは、アクセス許可が取得されるまで、それらの受信者URIに対する翻訳を実行しません。
URI-list services using request-contained URI lists are a special case because the selection of recipient URIs is performed at the same time as the communication attempt. A user places a set of recipient URIs in a request and sends it to a relay so that the relay sends a similar request to all those recipient URIs.
Request Conted URIリストを使用したURI-Listサービスは、受信者の選択が通信試行と同時に実行されるため、特別なケースです。ユーザーは、受信者のセットをリクエストに配置し、リレーに送信して、リレーがそれらのすべての受信者に同様のリクエストを送信するようにします。
Relays implementing this consent framework and providing request-contained URI-list services behave in a slightly different way than the relays described so far. This type of relay also maintains a list of recipient URIs for which permissions have been received. Clients also manipulate this list using a manipulation mechanism (e.g., XCAP). Nevertheless, this list does not represent the recipient URIs of every translation performed by the relay. This list just represents all the recipient URIs for which permissions have been received -- that is, the set of URIs that will be accepted if a request containing a URI-list arrives to the relay. This set of URIs is a superset of the recipient URIs of any particular translation the relay performs.
リレーこの同意フレームワークを実装し、リクエストで構成されたURI-Listサービスを提供することは、これまでに説明したリレーとはわずかに異なる方法で動作します。このタイプのリレーは、許可が受信された受信者URIのリストも維持しています。また、クライアントは操作メカニズム（XCAPなど）を使用してこのリストを操作します。それにもかかわらず、このリストは、リレーによって実行されるすべての翻訳の受信者のurisを表していません。このリストは、権限が受信されたすべての受信者URIを表すだけです。つまり、URIリストを含むリクエストがリレーに到着した場合に受け入れられるURIのセットです。このURISのセットは、リレーが実行する特定の翻訳の受信者URISのスーパーセットです。
On receiving a request-contained URI list, the relay checks whether or not it has permissions for all the URIs contained in the incoming URI list. If it does, the relay performs the translation. If it lacks permissions for one or more URIs, the relay MUST NOT perform the translation and SHOULD return an error response.
リクエストが含むURIリストを受信すると、リレーは、着信URIリストに含まれるすべてのURIの権限があるかどうかを確認します。もしそうなら、リレーは翻訳を実行します。1つ以上のURIのアクセス許可がない場合、リレーは翻訳を実行してはならず、エラー応答を返す必要があります。
A relay that receives a request-contained URI list with a URI for which the relay has no permissions SHOULD return a 470 (Consent Needed) response. The relay SHOULD add a Permission-Missing header field with the URIs for which the relay has no permissions.
リレーに許可を持たないURIを使用してリクエストで入ったURIリストを受信するリレーは、470（同意が必要）応答を返す必要があります。リレーは、リレーにアクセス許可がないURISに許可ミッシングヘッダーフィールドを追加する必要があります。
Figure 6 shows a relay that receives a request (1) that contains URIs for which the relay does not have permission (the INVITE carries the recipient URIs in its message body). The relay rejects the request with a 470 (Consent Needed) response (2). That response contains a Permission-Missing header field with the URIs for which there was no permission.
図6は、リレーに許可を持たないURIを含むリクエスト（1）を受信するリレーを示しています（招待状には、メッセージ本文に受信者がurisを運びます）。リレーは、470（同意が必要）応答（2）でリクエストを拒否します。その応答には、許可がないURIを使用した許可ミッシングヘッダーフィールドが含まれています。
A@example.com Relay
a@example.comリレー
|(1) INVITE |
| sip:B@example.com |
| sip:C@example.com |
|---------------------->|
|(2) 470 Consent Needed |
| Permission-Missing: sip:C@example.com
|<----------------------|
|(3) ACK |
|---------------------->|
Figure 6: INVITE with a URI List in Its Body
図6：その体にURIリストを招待する
A 470 (Consent Needed) response indicates that the request that triggered the response contained a URI list with at least one URI for which the relay had no permissions. A user agent server generating a 470 (Consent Needed) response SHOULD include a Permission-Missing header field in it. This header field carries the URI or URIs for which the relay had no permissions.
470（同意が必要）応答は、応答をトリガーしたリクエストに、リレーに許可がない少なくとも1つのURIを含むURIリストが含まれていることを示しています。470（同意が必要）の応答を生成するユーザーエージェントサーバーには、許可ミッシングヘッダーフィールドを含める必要があります。このヘッダーフィールドには、リレーに許可がないURIまたはURIが含まれます。
A user agent client receiving a 470 (Consent Needed) response without a Permission-Missing header field needs to use an alternative mechanism (e.g., XCAP) to discover for which URI or URIs there were no permissions.
許可ミッシングヘッダーフィールドなしで470（同意が必要）応答を受信するユーザーエージェントクライアントは、URIまたはURIが許可がなかった代替メカニズム（XCAPなど）を使用する必要があります。
A client receiving a 470 (Consent Needed) response uses a manipulation mechanism (e.g., XCAP) to add those URIs to the relay's list of URIs. The relay will obtain permissions for those URIs as usual.
470（同意が必要）を受け取るクライアントは、操作メカニズム（XCAPなど）を使用して、リレーのURIのリストにそれらを追加します。リレーは、通常どおりにそれらのURIの権限を取得します。
Permission-Missing header fields carry URIs for which a relay did not have permissions. The following is the augmented Backus-Naur Form (BNF) [RFC5234] syntax of the Permission-Missing header field. Some of its elements are defined in [RFC3261].
許可ミッシングヘッダーフィールドには、リレーに許可がないURIがあります。以下は、許可ミッシングヘッダーフィールドの構文の構文です。その要素の一部は[RFC3261]で定義されています。
Permission-Missing = "Permission-Missing" HCOLON per-miss-spec
*( COMMA per-miss-spec )
per-miss-spec = ( name-addr / addr-spec )
*( SEMI generic-param )
The following is an example of a Permission-Missing header field:
以下は、許可ミッシングヘッダーフィールドの例です。
Permission-Missing: sip:C@example.com
Even though the example used to specify this framework has been a URI-list service, this framework applies to any type of translation (i.e., not only to URI-list services). Registrations are a different type of translations that deserve discussion.
このフレームワークを指定するために使用される例はURIリストサービスでしたが、このフレームワークはあらゆるタイプの翻訳に適用されます（つまり、URI-Listサービスだけでなく）。登録は、議論に値する異なるタイプの翻訳です。
Registrations are a special type of translations. The user registering has a trust relationship with the registrar in its home domain. This is not the case when a user gives any type of permissions to a relay in a different domain.
登録は特別なタイプの翻訳です。ユーザー登録は、ホームドメインのレジストラとの信頼関係を持っています。これは、ユーザーが別のドメイン内のリレーにあらゆるタイプのアクセス許可を提供する場合ではありません。
Traditionally, REGISTER transactions have performed two operations at the same time: setting up a translation and authorizing the use of that translation. For example, a user registering its current contact URI is giving permission to the registrar to forward traffic sent to the user's AoR (Address of Record) to the registered contact URI. This works fine when the entity registering is the same as the one that will be receiving traffic at a later point (e.g., the entity receives traffic over the same connection used for the registration as described in [OUTBOUND]). However, this schema creates some potential attacks that relate to third-party registrations.
従来、登録トランザクションは同時に2つの操作を実行してきました。翻訳の設定とその翻訳の使用を許可します。たとえば、現在の連絡先を登録しているユーザーは、登録済みの連絡先のトラフィック（記録のアドレス）に送信されるトラフィックを登録された連絡先URIに転送する許可を与えています。これは、登録エンティティが後のポイントでトラフィックを受信するエンティティと同じである場合に正常に機能します（たとえば、エンティティは[アウトバウンド]で説明されているように登録に使用されるのと同じ接続を介してトラフィックを受信します）。ただし、このスキーマは、サードパーティの登録に関連する潜在的な攻撃を作成します。
An attacker binds, via a registration, his or her AoR with the contact URI of a victim. Now the victim will receive unsolicited traffic that was originally addressed to the attacker.
攻撃者は、登録を介して、被害者の接触URIと彼または彼女のAORに縛られます。現在、被害者は、もともと攻撃者に宛てられた未承諾のトラフィックを受け取ります。
The process of authorizing a registration is shown in Figure 7. User A performs a third-party registration (1) and receives a 202 (Accepted) response (2).
登録の承認プロセスを図7に示します。ユーザーAはサードパーティの登録を実行し（1）、202（受け入れられた）応答（2）を受信します。
Since the relay does not have permission from 'sip:a@ws123.example.com' to perform translations towards that recipient URI, the relay places 'sip:a@ws123.example.com' in the 'pending' state. Once 'sip:a@ws123.example.com' is in the 'Permission Pending' state, the registrar needs to ask 'sip:a@ws123.example.com' for permission by sending a MESSAGE request (3).
リレーは「sip：a@ws123.example.com」の許可を持っていないため、その受信者のuriに翻訳を実行するために、リレーは「保留中」状態で 'sip：a@ws123.example.com'をプレースします。「SIP：a@ws123.example.com」が「保留中の許可」状態になると、レジストラはメッセージリクエストを送信して許可を求めて「sip：a@ws123.example.com」を尋ねる必要があります（3）。
After receiving the response from the relay (2), user A subscribes to the Pending Additions event package at the registrar (5). This subscription keeps the user informed about the status of the permissions (e.g., granted or denied) the registrar will obtain. The rest of the process is similar to the one described in Section 5.
リレー（2）から応答を受け取った後、ユーザーAはレジストラ（5）で保留中の追加イベントパッケージを購読します。このサブスクリプションは、レジストラが取得する権限のステータス（付与または拒否など）について通知されます。残りのプロセスは、セクション5で説明されているプロセスと似ています。
A@example.com Registrar a@ws123.example.com
a@example.comレジストラa@ws123.example.com
|(1) REGISTER | |
| Contact: sip:a@ws123.example.com |
|------------------>| |
|(2) 202 Accepted OK| |
|<------------------| |
| |(3) MESSAGE sip:a@ws123.example
| | Permission Document
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) SUBSCRIBE | |
| Event: pending-additions |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
|(7) NOTIFY | |
|<------------------| |
|(8) 200 OK | |
|------------------>| |
| |(9) PUBLISH uri-up |
| |<------------------|
| |(10) 200 OK |
| |------------------>|
|(11) NOTIFY | |
|<------------------| |
|(12) 200 OK | |
|------------------>| |
Figure 7: Registration
図7：登録
Permission documents generated by registrars are typically very general. For example, in one such document a registrar can ask a recipient for permission to forward any request from any sender to the recipient's URI. This is the type of granularity that this framework intends to provide for registrations. Users who want to define how incoming requests are treated with a finer granularity (e.g., requests from user A are only accepted between 9:00 and 11:00) will have to use other mechanisms such as Call Processing Language (CPL) [RFC3880].
レジストラによって生成された許可文書は通常、非常に一般的です。たとえば、そのようなドキュメントの1つでは、レジストラは受信者に、送信者からのリクエストを受信者のURIに転送する許可を求めることができます。これは、このフレームワークが登録を提供することを意図している粒度のタイプです。受信リクエストがより細かい粒度でどのように扱われるかを定義したいユーザー（たとえば、ユーザーAからのリクエストは9:00から11:00の間にのみ受け入れられます）は、コール処理言語（CPL）[RFC3880]などの他のメカニズムを使用する必要があります。。
Note that, as indicated previously, user agents using the same connection to register and to receive traffic from the registrar, as described in [OUTBOUND], do not need to use the mechanism described in this section.
前述のように、[アウトバウンド]で説明されているように、同じ接続を使用してレジストラからトラフィックを受信するために同じ接続を使用してユーザーエージェントは、このセクションで説明されているメカニズムを使用する必要はないことに注意してください。
A user agent being registered by a third party can be unable to use the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to prove to the registrar that the user agent is the owner of the URI being registered (e.g., sip:user@192.0.2.1), which is the recipient URI of the translation. In this case, return routability MUST be used.
サードパーティによって登録されているユーザーエージェントは、SIP ID、Pアサート付きアイデンティティ、またはSIPダイジェストメカニズムを使用して、ユーザーエージェントが登録されているURIの所有者であることをレジストラに証明することができません（例：SIP：user@192.0.2.1）、これは翻訳の受信者URIです。この場合、返品ルーティング可能性を使用する必要があります。
Relays generating traffic towards recipients need to make sure that those recipients can revoke the permissions they gave at any time. The Trigger-Consent helps achieve this.
受信者に向かってトラフィックを生成するリレーは、それらの受信者がいつでも与えた権限を取り消すことができることを確認する必要があります。トリガーコンセントはこれを達成するのに役立ちます。
A relay executing a translation that involves sending a request to a URI from which permissions were obtained previously SHOULD add a Trigger-Consent header field to the request. The URI in the Trigger-Consent header field MUST have a target-uri header field parameter identifying the target URI of the translation.
以前にアクセス許可が取得されたURIにリクエストを送信する翻訳を実行するリレーは、リクエストにトリガーコンセントヘッダーフィールドを追加する必要があります。トリガーコンセントヘッダーフィールドのURIには、翻訳のターゲットURIを識別するターゲットURIヘッダーフィールドパラメーターが必要です。
On receiving a PUBLISH request addressed to the URI that a relay previously placed in a Trigger-Consent header field, the relay SHOULD send a MESSAGE request to the corresponding recipient URI with a permission document. Therefore, the relay needs to be able to correlate the URI it places in the Trigger-Consent header field with the recipient URI of the translation.
リレーが以前にトリガーコンセントヘッダーフィールドに配置されていたリレーを宛てたパブリッシュリクエストを受信すると、リレーは許可ドキュメントを使用して対応する受信者URIにメッセージリクエストを送信する必要があります。したがって、リレーは、翻訳のトリガーコンセントヘッダーフィールドに配置されたURIを相関させることができる必要があります。
The following is the augmented Backus-Naur Form (BNF) [RFC5234] syntax of the Trigger-Consent header field. Some of its elements are defined in [RFC3261].
以下は、トリガーコンセントヘッダーフィールドの構文の構文です。その要素の一部は[RFC3261]で定義されています。
Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec
*( COMMA trigger-cons-spec )
trigger-cons-spec = ( SIP-URI / SIPS-URI )
*( SEMI trigger-param )
trigger-param = target-uri / generic-param
target-uri = "target-uri" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT
The target-uri header field parameter MUST contain a URI.
ターゲット-URIヘッダーフィールドパラメーターには、URIが含まれている必要があります。
The following is an example of a Trigger-Consent header field:
以下は、トリガーコンセントヘッダーフィールドの例です。
Trigger-Consent: sip:123@relay.example.com
;target-uri="sip:friends@relay.example.com"
Per the following sections, IANA has registered a SIP response code, two SIP header fields, and a SIP header field parameter.
次のセクションに従って、IANAはSIP応答コード、2つのSIPヘッダーフィールド、およびSIPヘッダーフィールドパラメーターを登録しています。
IANA has added the following new response code to the Methods and Response Codes subregistry under the SIP Parameters registry.
IANAは、SIPパラメータレジストリの下で、メソッドおよび応答コードサブレジストリに次の新しい応答コードを追加しました。
Response Code Number: 470 Default Reason Phrase: Consent Needed Reference: [RFC5360]
応答コード番号：470デフォルトの理由フレーズ：同意が必要ですリファレンス：[RFC5360]
IANA has added the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.
IANAは、SIPパラメータレジストリの下で、次の新しいSIPヘッダーフィールドをヘッダーフィールドサブレジストリに追加しました。
Header Name: Trigger-Consent Compact Form: (none) Reference: [RFC5360]
ヘッダー名：トリガーコンセントコンパクトフォーム：（なし）リファレンス：[RFC5360]
IANA has added the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.
IANAは、SIPパラメータレジストリの下で、次の新しいSIPヘッダーフィールドをヘッダーフィールドサブレジストリに追加しました。
Header Name: Permission-Missing Compact Form: (none) Reference: [RFC5360]
ヘッダー名：許可ミッシングコンパクトフォーム：（なし）リファレンス：[RFC5360]
IANA has registered the 'target-uri' Trigger-Consent header field parameter under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry:
IANAは、SIPパラメーターレジストリ内のヘッダーフィールドパラメーターとパラメーター値サブレジストリの下で、「ターゲットウリ」トリガー依存ヘッダーフィールドパラメーターを登録しました。
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Trigger-Consent target-uri No [RFC5360]
Security has been discussed throughout the whole document. However, there are some issues that deserve special attention.
セキュリティはドキュメント全体を通して議論されています。ただし、特別な注意に値する問題がいくつかあります。
Relays generally implement several security mechanisms that relate to client authentication and authorization. Clients are typically authenticated before they can manipulate a relay's translation logic. Additionally, clients are typically also authenticated and sometimes need to perform SPAM prevention tasks [RFC5039] when they send traffic to a relay. It is important that relays implement these types of security mechanisms. However, they fall out of the scope of this framework. Even with these mechanisms in place, there is still a need for relays to implement this framework because the use of these mechanisms does not prevent authorized clients to add recipients to a translation without their consent. Consequently, relays performing translations MUST implement this framework.
リレーは一般に、クライアントの認証と承認に関連するいくつかのセキュリティメカニズムを実装します。クライアントは通常、リレーの翻訳ロジックを操作する前に認証されます。さらに、クライアントは通常、認証されており、リレーにトラフィックを送信するときにスパム予防タスク[RFC5039]を実行する必要があります。リレーはこれらのタイプのセキュリティメカニズムを実装することが重要です。しかし、それらはこのフレームワークの範囲から抜け出します。これらのメカニズムが整っていても、これらのメカニズムを使用しても、認定されたクライアントが同意なしに翻訳に受信者を追加することを妨げないため、このフレームワークを実装するリレーがまだ必要です。したがって、リレーを実行する翻訳を実行する必要があります。このフレームワークを実装する必要があります。
Note that, as indicated previously, user agents using the same connection to register and to receive traffic from the registrar, as described in [OUTBOUND], do not need to use this framework. Therefore, a registrar that did not accept third-party registrations would not need to implement this framework.
前述のように、[アウトバウンド]で説明されているように、同じ接続を使用してレジストラからトラフィックを受信するために同じ接続を使用して、このフレームワークを使用する必要はないことに注意してください。したがって、サードパーティの登録を受け入れなかったレジストラは、このフレームワークを実装する必要はありません。
As pointed out in Section 5.6.1.3, when return routability tests are used to authenticate recipients granting or denying permissions, the URIs used to grant or deny permissions need to be protected from attackers. SIPS URIs provide a good tool to meet this requirement, as described in [RFC5361]. When store-and-forward servers are used, the interface between a user agent and its store-and-forward server is frequently not based on SIP. In such a case, SIPS cannot be used to secure those URIs. Implementations of store-and-forward servers MUST provide a mechanism for delivering encrypted and integrity-protected messages to their user agents.
セクション5.6.1.3で指摘されているように、Return Rourabilityテストを使用して許可を付与または拒否する受信者を認証するために使用される場合、URIは許可を付与または拒否するために使用されます。SIPS URIは、[RFC5361]に記載されているように、この要件を満たすための優れたツールを提供します。ストアアンドフォワードサーバーを使用すると、ユーザーエージェントとそのストアアンドフォワードサーバーの間のインターフェイスは、SIPに基づいていないことがよくあります。そのような場合、SIPを使用してそれらのURIを保護することはできません。ストアアンドフォワードサーバーの実装は、ユーザーエージェントに暗号化された整合性と保護されたメッセージを配信するためのメカニズムを提供する必要があります。
The information provided by the Pending Additions event package can be sensitive. For this reason, as described in [RFC5362], relays need to use strong means for authentication and information confidentiality. SIPS URIs are a good mechanism to meet this requirement.
保留中の追加イベントパッケージによって提供される情報は、敏感です。このため、[RFC5362]で説明されているように、リレーは認証と情報の機密性に強力な手段を使用する必要があります。SIPS URISは、この要件を満たすための優れたメカニズムです。
Permission documents can reveal sensitive information. Attackers may attempt to modify them in order to have clients grant or deny permissions different from the ones they think they are granting or denying. For this reason, it is RECOMMENDED that relays use strong means for information integrity protection and confidentiality when sending permission documents to clients.
許可文書は、機密情報を明らかにすることができます。攻撃者は、クライアントに許可を付与したり、許可を与えたり否定していると思うかとは異なる権限を付与したり拒否したりするために、それらを変更しようとする場合があります。このため、クライアントに許可文書を送信する際に、リレーは情報の整合性保護と機密性のために強力な手段を使用することをお勧めします。
The mechanism used for conveying information to clients SHOULD ensure the integrity and confidentially of the information. In order to achieve these, an end-to-end SIP encryption mechanism, such as S/MIME, as described in [RFC3261], SHOULD be used.
クライアントに情報を伝えるために使用されるメカニズムは、情報の整合性と機密性を確保する必要があります。これらを達成するには、[RFC3261]に記載されているように、S/MIMEなどのエンドツーエンドのSIP暗号化メカニズムを使用する必要があります。
If strong end-to-end security means (such as above) are not available, it is RECOMMENDED that hop-by-hop security based on TLS and SIPS URIs, as described in [RFC3261], is used.
強力なエンドツーエンドのセキュリティ手段（上記など）が利用できない場合は、[RFC3261]に記載されているように、TLSとSIPS URIに基づくホップバイホップセキュリティを使用することをお勧めします。
Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided useful ideas on this document. Ben Campbell, AC Mahendran, Keith Drage, and Mary Barnes performed a thorough review of this document.
Henning Schulzrinne、Jon Peterson、およびCullen Jenningsは、この文書に有用なアイデアを提供しました。ベン・キャンベル、ACマヘンドラン、キース・ドレイジ、メアリー・バーンズは、この文書の徹底的なレビューを行いました。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[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月。
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、ed。、Ed。、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5361] Camarillo, G., "A Document Format for Requesting Consent", RFC 5361, October 2008.
[RFC5361] Camarillo、G。、「同意を要求するためのドキュメント形式」、RFC 5361、2008年10月。
[RFC5362] Camarillo, G., "The Session Initiation Protocol (SIP) Pending Additions Event Package", RFC 5362, October 2008.
[RFC5362] Camarillo、G。、「セッション開始プロトコル（SIP）保留中の追加イベントパッケージ」、RFC 5362、2008年10月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]カマリロ、G。およびA.B.Roach、「セッション開始プロトコル（SIP）URI-List Servicesのフレームワークとセキュリティ上の考慮事項」、RFC 5363、2008年10月。
[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月。
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[RFC3880] Lennox、J.、Wu、X。、およびH. Schulzrinne、「Call Processing Language（CPL）：インターネットテレフォニーサービスのユーザー制御用言語」、RFC 3880、2004年10月。
[RFC4453] Rosenberg, J., Camarillo, G., Ed., and D. Willis, "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 4453, April 2006.
[RFC4453] Rosenberg、J.、Camarillo、G.、Ed。、およびD. Willis、「セッション開始プロトコル（SIP）における同意ベースのコミュニケーションの要件」、RFC 4453、2006年4月。
[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月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826] Rosenberg、J。、「リソースリストを表すための拡張マークアップ言語（XML）形式」、RFC 4826、2007年5月。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5039] Rosenberg、J。およびC. Jennings、「セッション開始プロトコル（SIP）およびスパム」、RFC 5039、2008年1月。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, June 2007.
[Autbound] Jennings、C。and R. Mahy、「マネージングクライアントはセッション開始プロトコル（SIP）で接続を開始しました」、2007年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Iselin, NJ 08830 USA
ジョナサンローゼンバーグシスコイゼリン、ニュージャージー08830 USA
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンザロカマリロ（編集者）エリクソンハーサランティ11ジョルバス02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Dean Willis Unaffiliated 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
ディーン・ウィリス・アフィリオド3100独立PKWY＃311-164プラノ、テキサス75075 USA
EMail: dean.willis@softarmor.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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への情報をお問い合わせください。