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)
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]は、リアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、プレゼンスなど、いくつかのサービスのための通信をサポートしています。この通信は、通信が望まれると、受信者にイニシエータから（例えばINVITEとMESSAGE [RFC3428]など）は、種々のSIPリクエストを送信することによって確立されます。そのような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.
リレー：任意のSIPサーバ、それはプロキシ、B2BUA（バックツーバックユーザエージェント）を、または要求を受けたいくつかのハイブリッド、あること、一つ以上のネクストホップのURI（すなわち、受信者のURI）にその要求URIを変換、およびそれらのURIにリクエストを提供します。
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.
変換動作：動作リレーは、1つ以上の発信要求の要求-URIのように使用される1つの以上のURI（すなわち、レシピエントのURI）に着信要求（すなわち、ターゲット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.
リレーは、この枠組みの中で重要な役割を果たしています。リレーは、それがプロキシである、任意のSIPサーバとして定義され、B2BUA（バックツーバックユーザエージェント）、または要求を受信するいくつかのハイブリッドは、一つ以上の次のホップのURIにその要求URIを変換し、配信しますそれらのURIへの要求。図1に示すように、着信要求の要求URIが「ターゲットURI」と発信要求の宛先のURIと呼ばれるが、「受信者のURI」と呼ばれます。
+---------------+ 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.
このように、リレーの重要な側面は、翻訳のものです。リレーは、要求を受信すると、1つのまたは複数の追加のURI（受信者のURI）へのRequest-URI（ターゲットURI）を変換します。この翻訳作業を通じて、リレーは、このように同意の問題を作成し、1つの以上の追加の受信者のURIに発信要求を作成することができます。
The consent problem is created by two types of translations: translations based on local data and translations that involve amplifications.
ローカルデータと増幅を伴う翻訳に基づいて翻訳：同意の問題は、翻訳の二つのタイプによって作成されます。
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（ユーザーエージェント）にMESSAGE要求を配信することはできません一口：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をもたらす並進動作は、増幅の源です。このようアウトバウンドプロキシサーバとしての翻訳を実行していないサーバは、増幅が発生することはありません。ユーザが複数のエンドポイント（それによって複数の受信者のURIをもたらす）に到達することができる一方、変換を実行するサーバ（例えば、SIPドメインの権威担うインバウンドプロキシは）増幅を引き起こす可能性があります。
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」（：resource@example.com SIP）内のリソースを表すURIにSIPリクエストを送信します。この要求は、ローカルアウトバウンドプロキシ（図示せず）を通過し、最終的にドメイン「example.com」の権限のあるサーバーに到着することができます。リレーとして機能します。このサーバーは、1人のまたは複数の受信者に（必要ではないが）ドメイン「example.com」に属することができURIを、ターゲット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.
原則的に、権限は、彼らが有効であるか、それが取り消されるまで付与されたコンテキスト限り有効です。例えば、受信者のセットにMESSAGEリクエストを配布URIリストSIPサービスによって得られた権限は、URIリストの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が追加された）操作された場合、結果として、リレーは新たな変換論理をインストールするために、新たな受信者からの許可を取得します。リレーはMESSAGE [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リストサービスをホスティングしているリレーは、受信者のURIのセットにそのターゲットURIからの翻訳を行います。それかどうかを尋ね：クライアント（例えば、そのURIリストサービスの管理者が）新しい受信者URIとして「bob@example.org」を追加すると、リレーは「bob@example.org一口」にMESSAGEリクエストを送信します「：bob@example.org一口」に「friends@example.com一口」から変換を実行するためにOKです。 MESSAGEリクエストは、メッセージ本文にアクセス権が要求されている翻訳も翻訳を記述する判読可能な部分を説明し、許可文書を運びます。答えが肯定的である場合は、新しい変換ロジックは、リレーにインストールされています。つまり、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]とREGISTERトランザクションです。
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.
許可文書を持つMESSAGE要求は、それがリレーで送信された受信者URIに到着すると、受信側ユーザは、変換を実行するために必要な権限を付与または拒否することができます。しかし、MESSAGE要求が到着したときに受信側ユーザが使用できない場合や、一定期間のすべての着信要求をブロックする表明選好を持っていることがあります。このような場合には、ストアアンドフォワードサーバーは、ユーザーの代わりとして機能し、彼または彼女は再び利用可能になったとき、その後、ユーザーに配信されている受信メッセージの要求を、バッファリングすることができます。
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.
彼らは、自分の体で許可文書を持つものMESSAGE要求だけでなく、オフラインの間、同じストアアンドフォワードメッセージサービスは、ユーザーのすべての受信メッセージの要求を処理できることに注意してください。
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.
リレーが関連付けられているストアアンドフォワードサーバーを持っていないオフラインのユーザーエージェントからの許可を要求すると、リレーはそのMESSAGEリクエストが配信できなかったことを示すエラー応答を取得します。リレーの変換ロジックへのオフラインユーザーを追加しようとしたクライアントは、（保留中の追加イベントパッケージ[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（「B@example.com SIP」）受信者を追加するために、完全なプロセスを示しています。リレー（1）の変換ロジックに新しい受信者URIとして：ユーザーAは「B@example.com一口」を追加しようとします。ユーザAは、この加算を実行するためにXCAP [RFC4825]及びリソースリストを表現するためのXML（Extensible Markup Language）形式[RFC4826]を使用します。 [RFC5362]で指定されているように、保留状態：そのURIは、中継場所「B@example.com一口」に向けて翻訳を実行するために：リレーは「B@example.com一口」からアクセス許可を持っていませんので。
A@example.com Relay B's Store & Fwd B@example.com Server
A@example.comリレーBのストア＆早送り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は」いったん保留状態になって、リレーは「：B@example.com一口」にMESSAGEリクエストを送信することにより、許可をユーザー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を大量に追加します。リレーは、それらの受信者のURIのそれぞれにMESSAGEリクエストを送信します。リレーによって生成された帯域幅は、リレーの変換ロジックにそれらの受信者のURIを追加するために、攻撃者によって使用される帯域幅よりもはるかに高いだろう。
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へのMESSAGEリクエストを送信する際にリレーが生成されます帯域幅に匹敵する帯域幅の量を生成するために、翻訳にURIを追加し、ユーザーが必要です。 XCAPを使用する場合、この要件は、クライアントがHTTPトランザクションごとに複数のURIを追加することができないことによって満たされます。 REGISTERトランザクションを使用する場合、この要件は、クライアントがREGISTERトランザクションごとに複数の連絡先を登録することができないことによって満たされます。
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（競合）レスポンスを返すべきです。 [RFC4825]に記載されているようにXCAPサーバは、<制約障害>要素を使用してXML本体に拒否の理由を記述するべきです。クライアントは、単一のREGISTERトランザクションで複数の連絡先を登録しようとした場合、レジストラは、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.
リレーはMESSAGEリクエストを使用して、その変換ロジックに追加する可能性のある受信者からの許可を要求します。この例では、リレー（1）の変換ロジックにユーザBを追加する要求を受信すると、リレーは「：B@example.com SIP」に向かってMESSAGE要求（3）を生成します。このMESSAGEリクエストは、許可する必要があり、許可するか、その翻訳を実行するための中継許可を拒否するために、受信者が使用するURIのセットを運ぶ翻訳を記述する許可文書を、運びます。ユーザBがオフラインになっているので、MESSAGE要求は、ユーザBのストアアンドフォワードサーバーによってバッファリングされます。ユーザBは、後にオンラインに行くと5.6節で説明したように、それらのURIのいずれかを使用して翻訳を承認します。 MESSAGEリクエストも許可文書としてではなく、人間が読める形式で同じ情報が含まれている身体の部分を運びます。
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.
このフレームワークを実装リレーは、彼らの変換ロジックに追加する前に潜在的な受信者から許可を得なければなりません。リレーは、MESSAGE要求を使用して潜在的な受信者からの許可を要求します。
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-アサート・アイデンティティ[RFC3325]、リターン・ルータビリティ・テスト、またはSIPダイジェストです。 5.6節で指定されているリターン・ルータビリティ・テストからなる方法を使用するリレーは、SIPS URIへのMESSAGEリクエストを送信する必要があります。
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要求の一例です。すべてのヘッダフィールドは、簡単のために図示しているわけではありません。
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"
MESSAGEは、SIP：からbob@example.org SIP / 2.0：<SIP：alices-friends@example.com>;タグ= 12345678に<SIP：bob@example.org>のContent-Type：multipart / mixedの;境界=」 boundary1"
--boundary1 Content-Type: text/plain
--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
あなたが<SIP：alices-friends@example.com>に送信されたトラフィックを受信するために同意した場合は、次のURIのいずれかを使用してください：<一口：grant-1awdch5Fasddfce34@example.com>または<https://example.com/grant -1awdch5Fasddfce34>。 <一口：deny-23rCsdfgvdT5sdfgye@example.com>または<https://example.com/deny-23rCsdfgvdT5sdfgye>それ以外の場合は、次のURIのいずれかを使用します。 --boundary1のContent-Type：アプリケーション/ AUTH-政策+ 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>
<？xml version = "1.0" エンコード= "UTF-8"？> <CP：ルールセットのxmlns = "壷：IETF：のparams：XML：NS：同意-ルール" のxmlns：CP = "壷：IETF：のparams：XML ：NS：共通政策」のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> <CP：規則ID = "F1"> <CP：条件> <CP：アイデンティティ> < CP：多くの/> </ CP：アイデンティティ> <受信者> <CP：1つのID = "一口：bob@example.org" /> </受取人> <ターゲット> <CP：1 idは= "一口：アリス、友人@ 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--
</ CP：条件> <CP：アクション> <トランス取扱パーマ-URI = "一口：grant-1awdch5Fasddfce34@example.com">交付金</トランスハンドリング> <トランス取扱パーマ-URI = "HTTPS：/ /example.com/grant-1awdch5Fasddfce34 ">交付金</トランスハンドリング> <トランス取扱パーマ-URI =" 一口：deny-23rCsdfgvdT5sdfgye@example.com "> </トランス取り扱いを拒否> <トランスハンドリングperm- URI = "https://example.com/deny-23rCsdfgvdT5sdfgye">> </ CP </トランス取り扱いを拒否：アクション> <CP：変換/> </ CP：ルール> </ CP：ルールセット> --boundary1 -
A permission document is the representation (e.g., encoded in XML) of a permission. A permission document contains several pieces of data:
許可文書は、許可の表現（例えば、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.
受信者が文書で説明した変換を実行するためのリレー権限を付与するために使用することができたURI：URIが権限を付与します。リレーは許可文書のSIPとSIPS 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.
受信者が文書で説明した変換を実行するための中継許可を拒否するために使用することができたURI：URIが権限を拒否します。リレーは許可文書のSIPとSIPS 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
元の受信者のアイデンティティ：SIP：friends@example.com
Identity of the Final Recipient: sip:B@example.com
最終的な受信者のアイデンティティ：SIP：B@example.com
URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com
一口：URIは、許可を与えgrant-1awdch5Fasddfce34@example.com
URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34
https://example.com/grant-1awdch5Fasddfce34：URIは、権限を付与するには
URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com
一口：URIが権限を拒否するために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.
Senderフィールドには、多くの場合、ワイルドカードが含まれていることを期待されています。しかし、そのようなセクション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).
MESSAGE要求を受信すると（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 PUBLISHまたは文書に含まれている権限を付与するためのURIのいずれかにHTTP GETリクエストを送信することにより、許可文書で説明した翻訳を実行するためのリレー許可を与えます。同様に、受信者は、SIP PUBLISHまたは文書に含まれるアクセス許可を拒否するためのURIのいずれかにHTTP GETリクエストを送信することによって許可文書に記載の翻訳を実行するための中継許可を拒否する。要求が許可または拒否するための権限は空体を含んでいます。
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は、MESSAGE要求（3）そのストアアンドフォワードサーバーによって以前に受信された許可文書（10）を取得します。ユーザBは、許可文書に含まれるアクセス許可を付与するSIP URIに発行要求（11）を送信することによって受信された許可文書に記載の翻訳を許可します。
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 PUBLISHを保証しなければなりませんまたはHTTP GETリクエストは、翻訳の受け手ではなく、攻撃者によって生成された受信しました。リレーは、これらの要求を認証するために4つの方法を使用することができます：SIPアイデンティティ、P-アサート - アイデンティティ[RFC3325]、リターン・ルータビリティ・テスト、またはSIPダイジェスト。リターン・ルータビリティ・テストを認証するために使用することができるが、SIPは、PUBLISHとHTTP GETリクエスト、SIPアイデンティティを、P-アサート - アイデンティティ、およびSIPダイジェストのみSIPは、PUBLISHリクエストを認証するために使用することができます両方。 SIPダイジェストのみ中継（リレーと同じドメイン内にある、例えば、受信者）と秘密を共有する受信者を認証するために使用することができます。
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アイデンティティ[RFC4474]メカニズムは、PUBLISHリクエストの送信者を認証するために使用することができます。リレーは、PUBLISHリクエストの発信者が許可文書の受信者URIの所有者であることをチェックしなければなりません。それ以外の場合は、PUBLISHリクエストは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-アサート・アイデンティティ[RFC3325]メカニズムは、PUBLISHリクエストの送信者を認証するために使用することができます。 [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.
リレーは、PUBLISHリクエストの発信者が許可文書の受信者URIの所有者であることをチェックしなければなりません。それ以外の場合は、PUBLISHリクエストは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は、着信PUBLISHリクエストのための良好な認証メカニズムを提供します。それにも関わらず、SIPのアイデンティティはまだ公共のインターネット上で広く利用可能ではありません。すでにこの時点で使用可能な認証メカニズムが必要とされている理由です。
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.
リターン・ルータビリティ・テストは、SIPアイデンティティと同じレベルのセキュリティを提供していませんが、SIPアイデンティティメカニズムが利用できないアーキテクチャにおけるよりも良い何もセキュリティレベル（例えば、現在のインターネット）を提供します。リレーは、MESSAGE要求に許可文書に推測できないURI（すなわち、暗号ランダムユーザ部分を有する）と場所を生成する（3）。受信者は、要求またはそのURIに対してHTTP GETリクエストを発行するSIPを送信する必要があります。その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.
リターンルータビリティ方法は、許可文書の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への許可文書を持つMESSAGEリクエストを送らなければなりません。これは、攻撃者が（推測できない）URIへのアクセスを取得しないことを保証します。したがって、（推測できない）URIを使用できる唯一のユーザーは、メッセージリクエストの受信機です。同様に、リターン・ルータビリティ・テストを使用してリレーにより送信されたアクセス許可の書類だけで権限を付与し、否定する、セキュアなURI（すなわち、SIPSおよび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.
リレーは単に着信PUBLISH要求のためのSIPアイデンティティの使用を必要とすることによってSIP IDにリターン・ルータビリティ・テストから遷移することができます。つまり、そのようなリレーは、SIPのIDを使用していませんでしたPUBLISHリクエストを拒否します。
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ダイジェストメカニズムは、その送信者の株式限り、リレーとの秘密を公開要求の送信者を認証するために使用することができます。リレーは、PUBLISHリクエストの発信者が許可文書の受信者URIの所有者であることをチェックしなければなりません。それ以外の場合は、PUBLISHリクエストは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.
PUBLISH要求（11）を受信すると、リレーは、翻訳のための許可が受信されたこととリレーにおける変換ロジックが更新されたことをユーザAに通知するためのNOTIFY要求（13）を送信します。つまり、「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への空の本体とPUBLISHリクエストを送信する必要があります。このようなMESSAGE要求は以前に付与された権限を取り消すために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を取得する方法の一例を示しています。ユーザは、トリガ・同意ヘッダフィールドを含む着信INVITE（1）要求を拒否する。そのヘッダーフィールドにURIを使用して、ユーザは、リレーにPUBLISHリクエスト（4）を送信します。 PUBLISHリクエスト（4）を受信すると、リレーは、ユーザに向けてMESSAGE要求（6）を生成します。最後に、ユーザは、リレーにPUBLISH要求（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への変換を実行しません。
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.
受信者のURIの選択は通信の試みと同時に行われるので、リクエストに含まれるURIのリストを使用してURIリストサービスは特殊なケースです。ユーザーは、要求で受信者のURIのセットを配置し、リレーは、これらすべての受信者のURIに似たリクエストを送信するようにリレーに送信します。
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リストサービスの提供は、これまで説明してきたのリレーよりもわずかに異なる方法で動作します。リレーのこのタイプは、許可が受信されているため、受信者のURIのリストを保持します。また、クライアントは操作機構（例えば、XCAP）を使用して、このリストを操作します。それにもかかわらず、このリストは、リレーによって実行されるすべての翻訳の受信者のURIを表すものではありません。このリストは、ちょうど許可が受信されているため、すべての受信者のURIを表します - つまり、URIリストを含む要求がリレーに到着した場合には受け入れられるURIのセット。 URIのこのセットは、リレーが実行する任意の特定の翻訳の受信者のURIのスーパーセットです。
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.
リレー470（同意必要）レスポンスを返すべきでないアクセス権を持たないためにURIを持つリクエストに含まれるURIのリストを受信するリレー。リレーは、リレーが全く権限を持たないためにURIに許可欠落ヘッダフィールドを追加する必要があります。
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は、リレー（INVITEそのメッセージボディ内の受信者のURIを搬送する）権限を持っていないためにURIを含む要求（1）を受信するリレーを示します。リレー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リストにINVITE
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（同意必要）応答は、応答をトリガし、要求が中継無権限を有していなかったために少なくとも一つの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（同意必要）応答を受信したクライアントは、URIのリレーのリストにそれらのURIを追加する操作機構（例えば、XCAP）を使用しています。リレーは、いつものようにそれらの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を運びます。以下の許可欠損ヘッダフィールドの拡張バッカスナウア記法（BNF）[RFC5234]シンタックスです。その要素のいくつかは、[RFC3261]で定義されています。
Permission-Missing = "Permission-Missing" HCOLON per-miss-spec *( COMMA per-miss-spec ) per-miss-spec = ( name-addr / addr-spec ) *( SEMI generic-param )
許可ミッシング= "許可欠落" HCOLONあたりのミススペック*（COMMAあたりのミススペック）あたりのミススペック=（名前、アドレス/ ADDR-SPEC）*（SEMIジェネリック-PARAM）
The following is an example of a Permission-Missing header field:
以下の許可欠損ヘッダフィールドの例です。
Permission-Missing: sip:C@example.com
許可がありません：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リストサービスへの）翻訳の任意のタイプに適用されます。登録は議論に値する翻訳の異なるタイプです。
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.
翻訳を設定し、その翻訳文の使用を許可する：伝統的に、REGISTER取引は、同時に2つの操作を行っています。例えば、現在の連絡先URIを登録ユーザーは、登録された連絡先URIにユーザーのたAoR（レコードのアドレス）に送信されたトラフィックを転送するレジストラに許可を与えています。エンティティの登録は、後の時点でトラフィックを受信するものと同じである場合、これは正常に動作（例えば、エンティティは[OUTBOUND]で説明されるように登録するために使用されるのと同じ接続を介してトラフィックを受信します）。しかし、このスキーマは、サードパーティの登録に関連するいくつかの潜在的な攻撃を作成します。
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).
その受信者URIに向けて翻訳を実行するために、リレーの場所「SIP：a@ws123.example.com」「保留」状態：リレーは「a@ws123.example.com一口」からアクセス許可を持っていませんので。かつて「SIP：a@ws123.example.comは、」レジストラ「は一口：a@ws123.example.com」を依頼する必要があり、「許可保留」状態であるMESSAGEリクエストを送信することにより、許可を（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.
先に示したように、なお、登録すると、[OUTBOUND]に記載されているように、レジストラからのトラフィックを受信するために、同じ接続を使用して、ユーザエージェントは、このセクションで説明されたメカニズムを使用する必要はありません。
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.
ユーザエージェントは、ユーザエージェントは、URIの所有者は（例えば、SIP登録されているレジストラに証明するためにSIPアイデンティティ、P-アサート・アイデンティティ、または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.
PUBLISHリクエストを受信すると、リレーは、以前のトリガ・同意ヘッダフィールドに置かれていることURI宛、中継許可文書に対応する受信者URIにメッセージ要求を送信すべきです。したがって、リレーは、それが翻訳の受信者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].
以下は、トリガ・同意ヘッダフィールドの拡張バッカスナウア記法（BNF）[RFC5234]シンタックスです。その要素のいくつかは、[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
トリガ同意= "トリガー同意" HCOLONトリガ・短所スペック*（COMMAトリガ短所-SPEC）トリガー短所-specは=（SIP-URI / SIPS-URI）*（SEMIトリガーPARAM）トリガーPARAM =ターゲット-URI /ジェネリック-PARAM対象-URI = "ターゲット-URI" EQUAL LDQUOT *（qdtext /引用されたペア）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"
トリガー-同意：SIP：123@relay.example.com;ターゲット-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は、ヘッダーフィールドのパラメータの下にある「ターゲット-URI」トリガー・同意ヘッダーフィールドパラメータを登録しているとパラメータは、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.
リレーは、一般的に、クライアントの認証と承認に関連するいくつかのセキュリティメカニズムを実装しています。彼らは、リレーの変換ロジックを操作することができます前に、クライアントは一般的に認証されます。さらに、クライアントは一般的にも認証され、時には彼らは、リレーにトラフィックを送信するときSPAM防止タスク[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.
先に示したように、同じ接続を使用してユーザーエージェントが登録すると、レジストラからのトラフィックを受信するために、[OUTBOUND]に記載されているように、このフレームワークを使用する必要がないことに留意されたいです。そのため、サードパーティの登録を受け入れなかったレジストラは、このフレームワークを実装する必要はありません。
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で指摘したように、アクセス権を許可または拒否するために使用されるURIは、攻撃者から保護する必要があります。 [RFC5361]に記載されているようにURIが、この要件を満たすために優れたツールを提供するSIPS。ストアアンドフォワードのサーバーが使用される場合、ユーザエージェントとそのストアアンドフォワードサーバーとの間のインタフェースは、頻繁にSIPに基づくものではありません。このような場合には、SIPSは、それらの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 URIは、この要件を満たすために良い仕組みです。
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.
（上記のような）強力なエンドツーエンドのセキュリティ手段が利用可能でない場合、それはホップバイホップセキュリティTLSとSIPS URIのに基づいていることをお勧めしますが、[RFC3261]に記載されているように、使用されています。
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.
ヘニングSchulzrinneと、ジョンピーターソン、そしてカレン・ジェニングスは、この文書に便利なアイデアを提供しました。ベン・キャンベル、AC Mahendran、キース糖剤、およびメアリー・バーンズは、このドキュメントの徹底的な見直しを行いました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]キャンベル、B.、編。、ローゼンバーグ、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.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC5361] Camarillo, G., "A Document Format for Requesting Consent", RFC 5361, October 2008.
[RFC5361]キャマリロ、G.、 "同意を要求するためのドキュメントフォーマット"、RFC 5361、2008年10月。
[RFC5362] Camarillo, G., "The Session Initiation Protocol (SIP) Pending Additions Event Package", RFC 5362, October 2008.
[RFC5362]キャマリロ、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.ローチ、RFC 5363、2008年10月「セッション開始プロトコル（SIP）URIリストサービスのためのフレームワークとセキュリティの考慮事項」。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[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]レノックス、J.、呉、X.、およびH. Schulzrinneと、 "コール処理言語（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]ローゼンバーグ、J.、カマリロ、G.編、及びD.ウィリス、RFC 4453 "セッション開始プロトコル（SIP）に同意ベースの通信のための要件" 2006年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5039]ローゼンバーグ、J.とC.ジェニングス、 "セッション開始プロトコル（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.
[OUTBOUND]ジェニングス、C.とR.マーイ、進歩、2007年6月に仕事「セッション開始プロトコル（SIP）でのクライアント開始された接続の管理」を参照してください。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Iselin, NJ 08830 USA
ジョナサン・ローゼンバーグシスコアイセリン、NJ 08830 USA
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロ（エディタ）エリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Dean Willis Unaffiliated 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
ディーンウィリス無所属3100インディパークウェイ＃311から164プラノ、TX 75075 USA
EMail: dean.willis@softarmor.com
メールアドレス：dean.willis@softarmor.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。