RFC5360 日本語訳
5360 A Framework for Consent-Based Communications in the SessionInitiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D.Willis. October 2008. (Format: TXT=70658 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Rosenberg
Request for Comments: 5360 Cisco Systems
Category: Standards Track G. Camarillo, Ed.
Ericsson
D. Willis
Unaffiliated
October 2008
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 5360年のシスコシステムズカテゴリ: 2008年10月に属しないエド標準化過程G.キャマリロ、エリクソンのD.ウィリス
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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はリアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、および存在を含むいくつかのサービスのためのコミュニケーションをサポートします。 現在のフォームでは、それはセッション招待状、インスタントメッセージ、および1回のパーティーから別のパーティーまで受取人の明白な同意を必要としないで提供されるという他の要求を許します。 そのような同意がなければ、SIPが悪意の目的に使用されるのは、可能です、増幅とDoS(サービス妨害)攻撃を含んでいて。 このドキュメントはSIPの同意ベースのコミュニケーションのためにフレームワークを特定します。
Rosenberg, et al. Standards Track [Page 1] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[1ページ]。
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
1. 序論…3 2. 定義と用語…3 3. リレーと翻訳…4 4. アーキテクチャ…6 4.1. リレーでの許容…6 4.2. リレーの翻訳論理における同意操作…7 4.3. サーバを保存して、進めてください…8 4.4. 受取人は許可を与えます…9 4.5. このフレームワークを実装する実体…9 5. フレームワーク操作…9 5.1. 増幅回避…11 5.1.1. リレーの振舞い…12 5.2. 許可状態の購読…12 5.2.1. リレーの振舞い…13 5.3. 許可のために、要求します。13 5.3.1. リレーの振舞い…13 5.4. 許可ドキュメント構造…15 5.5. 許可は通知を要求しました…16 5.6. 許可交付金…17 5.6.1. リレーの振舞い…17 5.6.1.1. アイデンティティをちびちび飲んでください…17 5.6.1.2. Pはアイデンティティについて断言しました…17 5.6.1.3. Routabilityを返してください…18 5.6.1.4. ダイジェストをちびちび飲んでください…19 5.7. 許可は通知を承諾しました…19 5.8. 許可取消し…19 5.9. 要求で含まれたURIは記載します…20 5.9.1. リレーの振舞い…21 5.9.2. 470応答コードの定義…21 5.9.3. 許可をなくなったヘッダーフィールドの定義。22 5.10. 登録証明書…22 5.11. 受取人に向かってトラフィックを生成するリレー…25 5.11.1. リレーの振舞い…25 5.11.2. 引き金同意ヘッダーフィールドの定義…25 6. IANA問題…26 6.1. 470応答コードの登録…26 6.2. 引き金同意ヘッダーフィールドの登録…26 6.3. 許可をなくなったヘッダーフィールドの登録…26 6.4. 目標-uri Header Field Parameterの登録…26 7. セキュリティ問題…27 8. 承認…28 9. 参照…28 9.1. 標準の参照…28 9.2. 有益な参照…29
Rosenberg, et al. Standards Track [Page 2] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[2ページ]。
1. Introduction
1. 序論
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.
Session Initiationプロトコル(SIP)[RFC3261]はリアルタイムのオーディオ、ビデオ、テキスト、インスタントメッセージング、および存在を含むいくつかのサービスのためのコミュニケーションをサポートします。 このコミュニケーションは様々なSIP要求(INVITEやMESSAGE[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に加えるために基本的なフレームワークを定義します。
2. Definitions and Terminology
2. 定義と用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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: 実体(例えば、ユーザエージェントかプロキシ)によって送られた送信する要求のRequest-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(支持するために戻っているUserエージェント)、または何らかのハイブリッドであることにかかわらず要求を受け取って、1つ以上の次のホップURI(すなわち、受取人URI)にRequest-URIを翻訳して、それらのURIに要求を提供します。
Target URI: The Request-URI of an incoming request that arrives to a
relay that will perform a translation operation.
URIを狙ってください: 平行移動を実行するリレーに到達する入って来る要求のRequest-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つ以上の送信する要求のRequest URIとして使用される1つ以上のURI(すなわち、受取人URI)に入って来る要求(すなわち、目標URI)のRequest-URIを翻訳する操作。
Rosenberg, et al. Standards Track [Page 3] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[3ページ]。
3. Relays and Translations
3. リレーと翻訳
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(支持するために戻っているUserエージェント)、または何らかのハイブリッドであることにかかわらず要求を受け取って、1つ以上の次のホップURIにRequest-URIを翻訳して、それらのURIに要求を提供します。 入って来る要求のRequest-URIは'目標URI'と呼ばれます、そして、送信する要求の目的地URIは'受取人URI'と呼ばれます、図1に示されるように。
+---------------+ recipient URI
| |---------------->
| |
target URI | Translation | [...]
-------------->| Operation |
| | recipient URI
| |---------------->
+---------------+
+---------------+ 受取人URI| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 目標URI| 翻訳| [...] -------------->| 操作| | | 受取人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.
したがって、リレーの不可欠の局面は翻訳のものです。 リレーが要求を受け取るとき、それはRequest-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.
要求が直接終点に提供されるもの、いつまでにローカルの方針かローカルのデータ(登録証明書などの)に基づく平行移動はそうでなければそれが可能でない乗り物であるか。 言い換えれば、スパマーにユーザのアドレス、'一口: user@example.com 'があるなら、'一口: user@example.com 'をそのユーザが出席しているユーザエージェントに写像する登録データに近づく手段を持っていなくて、それはそのユーザのUA(ユーザエージェント)にMESSAGE要求を提供できません。 したがって、それはこの登録データの用法です、そして、より一般に、翻訳論理であり、望まれないコミュニケーションを防ぐためにそれが認可されると予想されます。 もちろん、スパマーがユーザエージェントのアドレスを知っていると、直接それに要求を提供できるでしょう。
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
1つ以上の受取人URIをもたらす平行移動は増幅の源です。 外国行きのプロキシサーバなどの翻訳を実行しないサーバが増幅を引き起こしません。 他方では、翻訳を実行するサーバ、(例えば、本国行きのプロキシ
Rosenberg, et al. Standards Track [Page 4] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[4ページ]。
authoritatively responsible for a SIP domain) may cause amplification if the user can be reached at multiple endpoints (thereby resulting in multiple recipient URIs).
厳然と責任がある、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'(一口: resource@example.com )のリソースを表すURIにSIP要求を送ります。 この要求は、地元の外国行きのプロキシ(目立たない)を通り抜けることができますが、結局、ドメイン'example.com'に、正式のサーバに到着します。 しかし、このサーバ(リレーとして機能する)は平行移動を実行します、そうすることができる1つ以上の受取人URIに目標URIを翻訳して()、ドメイン'example.com'に属さなければならなくなってください。 例えば、このリレーは、プロキシサーバかURIリストサービスであるかもしれません[RFC5363]。
+-------+
| |
>| UA |
/ | |
/ +-------+
/
/
+-----------------------+ /
| | /
+-----+ | Relay | / +-------+
| | | |/ | |
| UA |------>| |-------->| Proxy |
| | |+---------------------+|\ | |
+-----+ || Translation || \ +-------+
|| Logic || \
|+---------------------+| \ [...]
+-----------------------+ \
\
\ +-------+
\ | |
>| B2BUA |
| |
+-------+
+-------+ | | >| Ua| / | | / +-------+ / / +-----------------------+ / | | / +-----+ | リレー| / +-------+ | | | |/ | | | Ua|、-、-、-、-、--、>| |、-、-、-、-、-、-、--、>| プロキシ| | | |+---------------------+|\ | | +-----+ || 翻訳|| \ +-------+ || 論理|| \ |+---------------------+| \ [...] +-----------------------+ \ \ \ +-------+ \ | | >| 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.
翻訳の潜在的受取人は、リレー実行を与えることによって実際の受取人がトラフィックを彼らに送る翻訳許可であったならこのフレームワークで同意できます。
Rosenberg, et al. Standards Track [Page 5] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[5ページ]。
4. Architecture
4. アーキテクチャ
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 |
| |
+-------------+
+-----------------------+ 許可+-------------+ | | 要求| | +--------+ | リレー|、-、-、-、-、-、-、-、-、-、--、>| ストアとFwd| | | | | | サーバ| | クライアント| | | | | | | |+-------+ +-----------+| +-------------+ +--------+ ||Transl、||許容|| | | ||論理| | || 許可| | |+-------+ +-----------+| 要求| | +-----------------------+ V| ^ ^ +-------------+ | 操作| | 許可交付金| | +---------------+ +-------------------| 受取人| | | +-------------+
Figure 3: Reference Architecture
図3: 参照アーキテクチャ
4.1. Permissions at a Relay
4.1. リレーでの許容
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サービスが存在している限り、許容が取り消されるまで、1セットの受取人にMESSAGE要求を広げるURIリストSIPサービスで得られた許容は有効になるでしょう。
Rosenberg, et al. Standards Track [Page 6] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[6ページ]。
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.
さらに、受取人がリレーの翻訳論理から外されるなら、リレーSHOULDはその受取人と関係がある許容を削除します。 例えば、接触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.
また、リレーが、定期的に彼らの許容をリフレッシュするよう受取人に要求するのは、RECOMMENDEDです。 受取人が一定期間にわたって許容をリフレッシュしないなら、リレーSHOULDはその受取人と関係がある許容を削除します。
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.
異なったアプリケーションがそれらの値を設定するという異なった要件を持つことができるので、このフレームワークは軽い飲食物間隔の値のための少しの指導も提供しません。 例えば、費やすこのフレームワークを実装しない受取人に対応すると、より長い間隔が選ばれるかもしれないリレーはリフレッシュします。 彼らのユーザによって手動で実行されるようにそのような受取人が持っている加工処理したコネをリフレッシュしてください、そして、(受取人がこのフレームワークを実装しないので)また、ショートがあって、間隔をリフレッシュしてください。それらのユーザには、重過ぎる負担になってもよいです。
4.2. Consenting Manipulations on a Relay's Translation Logic
4.2. リレーの翻訳論理における同意操作
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.
例えば、'一口: friends@example.com 'でURIリストサービスを主催するリレーはその目標URIから1セットの受取人URIまでの翻訳を実行します。 クライアント(例えば、そのURIリストサービスの管理者)が新しい受取人URIとして' bob@example.org 'を加えるとき、リレーは'一口: friends@example.com 'から'一口: bob@example.org 'までの翻訳を実行するのがOKであるかどうか尋ねる'一口: bob@example.org 'にMESSAGE要求を送ります。 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.
人間読み込み可能な部分は、許可ドキュメントを理解していないユーザエージェントがユーザへの賢明な方法でまだ要求を処理していて、それを表示できるように、含まれています。
Rosenberg, et al. Standards Track [Page 7] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[7ページ]。
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 Configuration Accessプロトコル(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).
どのような場合でも、このフレームワークがSHOULDであると実装するリレーが特定の受取人URIが[RFC5362](すなわち、否定されたか、与えられた未定の、そして、待っている誤り)で指定された州にあるのを示す手段を持っています。
4.3. Store-and-Forward Servers
4.3. サーバを保存して、進めてください。
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要求が到着するとき、受信ユーザが手があかなかったかもしれませんか、またはそれは、ある期間を求めるすべての入って来る要求を妨げるために好みを言い表したかもしれません。 そのような場合、店とフォワードサーバは入って来る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要求だけではなく、ユーザを求めるそれらがオフラインである間のすべての入って来る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.
店とフォワードサーバが役に立つ機能を実行して、ほとんどのドメインで配布されると予想されますが、いくつかのドメインは着手からそれらを配布しないでしょう。 しかしながら、店とフォワードサーバのないドメインのユーザエージェントとリレーはまだこの同意フレームワークを使用できます。
Rosenberg, et al. Standards Track [Page 8] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[8ページ]。
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要求を提供できなかったのを示す誤り応答を得るでしょう。 リレーの翻訳論理にオフラインユーザを追加するのを試みたクライアントは誤り(例えば、Pending Additionsイベントパッケージ[RFC5362]を使用する)に関して通知されるでしょう。 ユーザがオンラインであるときに、このクライアントは、希望をいだいて後のポイントで同じユーザを加えるのを試みるかもしれません。 クライアントは、ユーザが例えば存在サービスを利用することによってオンラインであるかどうか発見できます。
4.4. Recipients Grant Permissions
4.4. 受取人は許可を与えます。
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 PUBLISH要求かHTTP GET要求を使用することで許容をリレーに提供します。
4.5. Entities Implementing This Framework
4.5. このフレームワークを実装する実体
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]で指定されたPending Additionsイベントパッケージを支えるのを含んでいるこのフレームワークを実装するのは、RECOMMENDEDです、と許可ドキュメントのための形式が[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で議論するように。 しかしながら、これはこのフレームワークに特定の要件ではなく、店とフォワードサーバのための一般的な要件です。
5. Framework Operations
5. フレームワーク操作
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.
このセクションは、prototypical呼び出し流動に関する例を使用することでこの同意フレームワークを指定します。 セクション4(すなわち、リレー、翻訳、および店とフォワードサーバ)で説明された要素はこの呼び出し流動における重要な役割をプレーします。
Rosenberg, et al. Standards Track [Page 9] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[9ページ]。
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 ')をリレーの翻訳論理に追加するために完全なプロセスを示しています。 ユーザAは、新しい受取人URIとして'一口: B@example.com 'をリレー(1)の翻訳論理に追加するのを試みます。 ユーザAは、この追加を実行するために、リソースリスト[RFC4826]を表すのにXCAP[RFC4825]とXML(拡張マークアップ言語)形式を使用します。 そのURIに向かって翻訳を実行するためにリレーには許可が'一口: B@example.com 'からないので、リレーは'一口: B@example.com 'を未定の状態に置きます、[RFC5362]で指定されるように。
Rosenberg, et al. Standards Track [Page 10] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[10ページ]。
A@example.com Relay B's Store & Fwd B@example.com
Server
A@example.com リレービーズストアと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 | | |
|--------------->| | |
| (1) 受取人を加えてください。| | | 一口: B@example.com | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(2) HTTP202(受け入れます)| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| |(3) MESSAGE一口: B@example | | | 許可ドキュメント| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(4) 202は受け入れました。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(5) 登録| | | | イベント: 未定の追加| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(6) 200 OK| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(7) 通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(8) 200 OK| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| |ユーザBは行きます。| | | | オンライン| | |(9) 要求| | | | 保存されたメッセージ| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(10) 配送| | | | 保存されたメッセージ| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(11) 上にPUBLISH uri| | |<--------------------------------| | |(12) 200 OK| | | |-------------------------------->| |(13) 通知してください。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(14) 200 OK| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|
Figure 4: Prototypical Call Flow
図4: Prototypicalは、流れと呼びます。
5.1. Amplification Avoidance
5.1. 増幅回避
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.
'一口: B@example.com 'が未定の状態にいったんあると、リレーは、'一口: B@example.com 'にMESSAGE要求を送ることによってユーザBに許可を求める必要があります。 しかしながら、リレーは、それが増幅攻撃に着手するのにアンプとして使用されないのを保証する必要があります。
Rosenberg, et al. Standards Track [Page 11] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[11ページ]。
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.
このフレームワークは、ただ説明された攻撃を避けるのにクレジットベースの承認メカニズムを使用します。 要求をMESSAGEに送るときリレーが生成する帯域幅に匹敵する帯域幅の量をそれらの受取人URIに向かって生成するのが新しい受取人URIを翻訳に追加しているユーザを必要とします。 XCAPが使用されているとき、クライアントがHTTPトランザクションあたり1つ以上のURIを加えるのを許容しないことによって、この必要条件は満たされます。 REGISTERトランザクションが使用されているとき、クライアントがREGISTERトランザクションあたり1つ以上の接触を登録するのを許容しないことによって、この必要条件は満たされます。
5.1.1. Relay's Behavior
5.1.1. リレーの振舞い
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).
このフレームワークを実装するリレーで、クライアントは1トランザクションあたり1つ以上の受取人URIを加えることができてはいけません。 XCAPを使用しているクライアントが、ただ一つのHTTPトランザクションにおける1つ以上の受取人URIを加えるのを試みるなら、XCAPサーバSHOULDはHTTP409(闘争)応答を返します。 XCAPサーバSHOULDは、>同じくらい要素であって、中で同じくらい説明された<規制失敗[RFC4825]を使用することでXMLボディーでの拒否の理由について説明します。 クライアントが、ただ一つのREGISTERトランザクションにおける1つ以上の接触を登録するのを試みるなら、記録係SHOULDは理由句(例えば、最大の1登録あたり1つの接触)でSIP403応答を返して、拒否の理由について説明します。
5.2. Subscription to the Permission Status
5.2. 許可状態の購読
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.
クライアントはそれらが要求した操作の状態に関して知識があるようになる方法を必要とします。 さもなければ、ユーザは、実際に既に失敗したとき、操作が成功するのを待つことができます。 特に後で要求を再試行するのを知るクライアントの必要性でない同意を求める要求の目標が届かないで、また関連店とフォワードサーバを持っていなかったなら。 Pending Additions 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.
クライアントは、それらが要求した操作の状態に関して知識があるのにPending Additions SIPイベントパッケージを使用できます。 すなわち、クライアントに操作(例えば、リレーの翻訳論理への受取人URIの追加)がいつ認可されるか(そして、このようにして実行されます)、または拒絶されるかを知らされるでしょう。 クライアントは'未定の追加'イベントパッケージに加入するために操られるSIP翻訳の目標URIを使用します。
Rosenberg, et al. Standards Track [Page 12] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[12ページ]。
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)でPending Additionsイベントパッケージに加入します。 この購読は、リレーが得る許容(例えば、与えるか、または否定する)の状態に関してユーザAに知らせ続けます。
5.2.1. Relay's Behavior
5.2.1. リレーの振舞い
Relays SHOULD support the Pending Additions SIP event package specified in [RFC5362].
SHOULDがPending Additions SIPイベントパッケージを支えるリレーは[RFC5362]で指定しました。
5.3. Request for Permission
5.3. 許可を求める要求
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を追加するという要求を受け取るとき、リレーは、MESSAGEが要求(3)であると'一口: B@example.com 'に向かって生成します。 このMESSAGE要求は、許可ドキュメントを運んで、与える受取人によって使用されるか、またはその翻訳を実行するリレー許可を否定するために1セットのURIを運びます。(ドキュメントは認可される必要がある翻訳について説明します)。 ユーザBがオフラインであるのでMESSAGE要求がユーザビーズ店によってバッファリングされる、-前方、サーバユーザBは後でそれらのURIの1つを使用することによって翻訳を認可しにオンラインで行くでしょう、セクション5.6で説明されるように。 また、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で説明されたメソッドのいずれも使用できます。
5.3.1. Relay's Behavior
5.3.1. リレーの振舞い
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]、リターンroutabilityテスト、またはSIPダイジェストです。 リターンroutabilityテストから成るメソッドを使用するリレーは彼らのMESSAGE要求をSIPS URIに送らなければなりません、セクション5.6で指定されるように。
Rosenberg, et al. Standards Track [Page 13] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[13ページ]。
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.
許容が許可ドキュメントとSHOULDを含まなければならないよう要求するために送られたMESSAGE要求は彼らのボディーに人間読み込み可能な部分を含んでいます。 人間読み込み可能な部分は許可ドキュメント(しかし人間が読める形式で)と同じ情報を含んでいます、許容を承諾して、否定するためにURIを含んでいて。 許可ドキュメントを理解していないユーザエージェントは、ユーザへの賢明な方法でまだ要求を処理していて、それを表示できます、彼らがいかなる他のインスタントメッセージも表示するだろうというとき。 この道、ユーザエージェントがこのフレームワークを実装しないでも、(人間)のユーザは許容を承諾するか、または否定するために手動で正しいURIをクリックできるでしょう。 ↓これは、人間の読み込み可能な部分を運ぶMESSAGE要求に関する例と許可ドキュメントです、ボディーで。(それは、[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"
MESSAGE一口: bob@example.org SIP/2.0From: <一口: alices-friends@example.com 、gt;、;=12345678To:にタグ付けをしてください <一口: bob@example.org 、gt;、コンテントタイプ: 複合/は混入しました; 境界は"boundary1""と等しいです。
--boundary1 Content-Type: text/plain
--boundary1コンテントタイプ: テキスト/平野
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
あなたが、<一口: alices-friends@example.com に送られたトラフィックを受けることを同意する、gt;、以下のURIの1つを使用してください: または、<一口: grant-1awdch5Fasddfce34@example.com 、gt;、lt;、交付金https://example.com/1awdch5Fasddfce34>。 さもなければ、以下のURIの1つを使用してください: または、<一口: deny-23rCsdfgvdT5sdfgye@example.com 、gt;、lt;、23rCsdfgvdT5sdfgyeをhttps://example.com/否定している>。 --boundary1コンテントタイプ: アプリケーション/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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><cp: ruleset xmlns=「つぼ:ietf:params:xml:ナノ秒: 同意規則」xmlns xmlns: : cp=「つぼ:ietf:params:xml:ナノ秒: 共通政策」xsi=、「 http://www.w3.org/2001/XMLSchema-instance 、「><cp: 規則イドは「f1"><cp: 状態><は以下をcpすること」と等しいです; アイデンティティ><cp: 多くの/></cp: アイデンティティ><受取人><cp: あるイド=「一口: bob@example.org 」/、gt;、</受取人><目標><cp: あるイドが「一口: alices-friends@example.com 」/と等しい、gt;、lt;、/目的の>。
Rosenberg, et al. Standards Track [Page 14] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[14ページ]。
</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:; 動作><cp: 変換/></cp: ></cp: ruleset>--boundary1を統治してください--
5.4. Permission Document Structure
5.4. 許可ドキュメント構造
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の使用をサポートするかもしれません。
Rosenberg, et al. Standards Track [Page 15] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[15ページ]。
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にも合っているでしょう。 しかしながら、受取人ユリをwildcardedしてはいけません。
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:
私たちの例では、リレーで送られたMESSAGE要求(3)における許可ドキュメントは以下の値を含んでいます:
Identity of the Sender: Any sender
送付者のアイデンティティ: どんな送付者
Identity of the Original Recipient: sip:friends@example.com
オリジナルの受取人のアイデンティティ: 一口: friends@example.com
Identity of the Final Recipient: sip:B@example.com
最終的な受取人のアイデンティティ: 一口: 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
許可を与えるURI: https://example.com/grant-1awdch5Fasddfce34
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リストにかかわるシナリオは特定の送付者に適用される許可ドキュメントを必要とすることができます。 送付者のアイデンティティが重要である場合では、リレーは送付者を認証しなければなりません。
5.5. Permission Requested Notification
5.5. 許可は通知を要求しました。
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は店とフォワードサーバが(9)を保存したというすべての要求をとって来ます。
Rosenberg, et al. Standards Track [Page 16] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[16ページ]。
5.6. Permission Grant
5.6. 許可交付金
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かHTTP GET要求をURIの1つに送ることによって説明された翻訳を実行するリレー許可を与えます。 同様に、受取人は許可ドキュメントでドキュメントに含まれた許容を否定するためにSIP PUBLISHかHTTP GET要求をURIの1つに送ることによって説明された翻訳を実行するリレー許可を否定します。 許容を承諾するか、または否定するという要求は空のボディーを含んでいます。
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は、PUBLISH要求(11)をSIP URIに送ることによって受け取られた許可ドキュメントで説明された翻訳が許可ドキュメントに含まれた許容を承諾するのを認可します。
5.6.1. Relay's Behavior
5.6.1. リレーの振舞い
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]、リターンroutabilityテスト、またはSIPが読みこなします。 SIP PUBLISHとHTTP GET要求の両方を認証するのにリターンroutabilityテストを使用できる間、SIP PUBLISH要求を認証するのに、アイデンティティ、アイデンティティであると断言されたP、およびSIPが読みこなすSIPを使用できるだけです。 リレー(例えばリレーと同じドメインにいる受取人)と秘密を共有する受取人を認証するのにSIPダイジェストを使用できるだけです。
5.6.1.1. SIP Identity
5.6.1.1. 一口のアイデンティティ
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.
PUBLISH要求の送付者を認証するのにSIPのアイデンティティ[RFC4474]メカニズムを使用できます。 リレーは、PUBLISH要求の創始者が許可ドキュメントの受取人URIの所有者であることをチェックしなければなりません。 さもなければ、PUBLISHはSHOULDを401の(権限のない)の応答で反応して、さらに処理してはいけないよう要求します。
5.6.1.2. P-Asserted-Identity
5.6.1.2. アイデンティティであると断言されたP
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.
また、PUBLISH要求の送付者を認証するのにアイデンティティであると断言されたP[RFC3325]メカニズムを使用できます。 しかしながら、[RFC3325]で議論するように、信じられたSIPサーバのネットワークだけの中でこのメカニズムが使用されることを意図します。 すなわち、このメカニズムの使用は管理ドメインの中で以前に同意している方針で適切であるだけです。
Rosenberg, et al. Standards Track [Page 17] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[17ページ]。
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はSHOULDを401の(権限のない)の応答で反応して、さらに処理してはいけないよう要求します。
5.6.1.3. Return Routability
5.6.1.3. リターンRoutability
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のアイデンティティは入って来る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.
リターンroutabilityテストはSIPのアイデンティティへの同じレベルのセキュリティを提供しませんが、それらはSIPアイデンティティメカニズムが利用可能でないアーキテクチャ(例えば、現在のインターネット)にないよりましなセキュリティー・レベルを提供します。 リレーは、「蹄-可能」URI(すなわち、aで、暗号で、任意のユーザーは離れている)を生成して、MESSAGE要求(3)に許可ドキュメントにそれを置きます。 受取人は、SIP PUBLISH要求かHTTP GET要求をそのURIに送る必要があります。 リレーで認証されていた状態で考えられて、どんな入って来る要求もそのURI SHOULDに発信しました。
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.
リターン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.
この認証を実行するのにリターンroutabilityテストを使用するリレーは許可ドキュメントによるMESSAGE要求をSIPS URIに送らなければなりません。 これは、攻撃者が(「蹄-可能」)URIに近づく手段を得ないのを確実にします。 したがって、(「蹄-可能」)URIを使用するのにおいて有能な唯一のユーザがMESSAGE要求の受信機です。 同様に、リターンroutabilityテストを使用しながらリレーで送られた許可ドキュメントは、与える安全な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.
リレーは単にSIPのアイデンティティの入って来るPUBLISH要求の使用を必要とするのによるリターンroutabilityテストからSIPのアイデンティティまでの変遷をそうすることができます。 すなわち、そのようなリレーはSIPのアイデンティティを使用しなかったPUBLISH要求を拒絶するでしょう。
Rosenberg, et al. Standards Track [Page 18] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[18ページ]。
5.6.1.4. SIP Digest
5.6.1.4. 一口ダイジェスト
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.
その送付者がリレーと秘密を共有する限り、PUBLISH要求の送付者を認証するのにSIPダイジェストメカニズムを使用できます。 リレーは、PUBLISH要求の創始者が許可ドキュメントの受取人URIの所有者であることをチェックしなければなりません。 さもなければ、PUBLISHはSHOULDを401の(権限のない)の応答で反応して、さらに処理してはいけないよう要求します。
5.7. Permission Granted Notification
5.7. 許可は通知を承諾しました。
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)を送ります。 すなわち、'一口: B@example.com 'は受取人URIとして加えられます。
5.8. Permission Revocation
5.8. 許可取消し
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があるTrigger同意ヘッダーフィールドを含むでしょう。 そのTrigger-同意ヘッダーフィールドには、翻訳の目標URIを特定する目標-uriヘッダーフィールドパラメタがあるでしょう。 受取人は、リレーからMESSAGE要求を受け取るためにTrigger-同意ヘッダーフィールドにおける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を失ったユーザが入って来る要求のTrigger-同意ヘッダーフィールドを使用することでどう新しいURIを得ることができるかに関する例を示しています。 ユーザは入って来るINVITE(1)要求を拒絶します。(それは、Trigger-同意ヘッダーフィールドを含みます)。 そのヘッダーフィールドにURIを使用して、ユーザはPUBLISH要求(4)をリレーに送ります。 PUBLISH要求(4)を受け取ると、リレーは、MESSAGEが要求(6)であるとユーザに向かって生成します。 最終的に、ユーザは、PUBLISH要求(8)をリレーに送ることによって、許容を取り消します。
Rosenberg, et al. Standards Track [Page 19] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[19ページ]。
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 |
|---------------------------->|
リレー B@example.com |(1) 招待| | 引き金同意: 一口: 123@relay.example.com | ; 目標-uriは「一口: friends@relay.example.com 」と等しいです。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(2) 603衰退| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(3) ACK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(4) PUBLISH一口: 123@relay.example.com | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(5) 200 OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(6) MESSAGE一口: B@example | | 許可ドキュメント| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(7) 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(8) PUBLISH uri否定します。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(9) 200 OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|
Figure 5: Permission Revocation
図5: 許可取消し
5.9. Request-Contained URI Lists
5.9. 要求で含まれたURIリスト
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リストサービスは特別なケースです。 ユーザは、1セットの受取人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
この同意フレームワークと提供を実装するリレーは、含まれたURIリストサービスがわずかに今までのところ説明されているリレーと異なった方法で振る舞うよう要求します。 また、このタイプのリレーは許容が受けられた受取人URIのリストを維持します。 また、クライアントは、操作メカニズム(例えば、XCAP)を使用することでこのリストを操ります。 それにもかかわらず、このリストはリレーで実行されたあらゆる翻訳の受取人URIを表しません。 このリストはただ、許容が受けられたすべての受取人URI()を表します、受け入れられるURIのセット
Rosenberg, et al. Standards Track [Page 20] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[20ページ]。
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はリレーが実行するどんな特定の翻訳の受取人URIのスーパーセットです。
5.9.1. Relay's Behavior
5.9.1. リレーの振舞い
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のための許容を欠いているなら、リレーは翻訳を実行してはいけません、そして、SHOULDは誤り応答を返します。
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.
どんな許容SHOULDもリレーで470(必要である同意)応答を返さないURIで要求で含まれたURIリストを受け取るリレー。 リレーSHOULDはリレーには許容が全くないURIでPermissionをなくなったヘッダーフィールドを加えます。
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)を受け取るのを(INVITEはメッセージ本体で受取人URIを運びます)リレーに示します。 リレーは470(必要である同意)応答(2)で要求を拒絶します。 その応答は許可が全くなかったURIがあるPermissionをなくなったヘッダーフィールドを含んでいます。
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 |
|---------------------->|
| (1) 招待| | 一口: B@example.com | | 一口: C@example.com | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(2) 同意が必要とした470| | なくなる許可を: 一口: C@example.com | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(3) ACK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|
Figure 6: INVITE with a URI List in Its Body
図6: 中にURIリストがあるボディーを招待してください。
5.9.2. Definition of the 470 Response Code
5.9.2. 470応答コードの定義
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リストを含んだのを示します。 SHOULDが含む470(必要である同意)応答にそれのPermissionをなくなったヘッダーフィールドを生成するユーザエージェントサーバ。 このヘッダーフィールドはリレーには許容が全くなかったURIかURIを運びます。
Rosenberg, et al. Standards Track [Page 21] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[21ページ]。
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.
Permissionをなくなったヘッダーフィールドなしで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のために許可を得るでしょう。
5.9.3. Definition of the Permission-Missing Header Field
5.9.3. 許可をなくなったヘッダーフィールドの定義
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を運びます。 ↓これはPermissionをなくなったヘッダーフィールドの増大しているBN記法(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 / addr仕様)。(SEMIジェネリック-param)
The following is an example of a Permission-Missing header field:
↓これはPermissionをなくなったヘッダーフィールドに関する例です:
Permission-Missing: sip:C@example.com
なくなる許可を: 一口: C@example.com
5.10. Registrations
5.10. 登録証明書
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
伝統的に、REGISTERトランザクションは同時に、2つの操作を実行しました: 翻訳をセットアップして、その翻訳の使用を認可します。 例えば、現在の接触URIを登録するユーザは、ユーザのAoR(Recordのアドレス)に送られたトラフィックを登録された接触URIに送るために記録係に許可しています。 実体登録が後のポイントでトラフィックを受けるものと同じであるときに、これがきめ細かに働いている、(例えば、実体
Rosenberg, et al. Standards Track [Page 22] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[22ページ]。
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.
登録に[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に向かって翻訳を実行するためにリレーには許可が'一口: a@ws123.example.com 'からないので、リレーは'一口: a@ws123.example.com 'を'未定'の状態に置きます。 '一口: a@ws123.example.com 'が'許可Pending'状態にいったんあると、記録係は、MESSAGE要求(3)を送ることによって'一口: a@ws123.example.com 'に許可を求める必要があります。
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)でPending Additionsイベントパッケージに加入します。 この購読は、記録係が得る許容(例えば、与えるか、または否定する)の状態に関してユーザに知らせ続けます。 プロセスの残りはセクション5で説明されたものと同様です。
Rosenberg, et al. Standards Track [Page 23] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[23ページ]。
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 | |
|------------------>| |
| (1) 登録してください。| | | 接触: 一口: a@ws123.example.com | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(2) 202はOKを受け入れました。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| |(3) MESSAGE一口: a@ws123.example | | 許可ドキュメント| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(4) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(5) 登録| | | イベント: 未定の追加| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(6) 200 OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(7) 通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(8) 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |(9) 上にPUBLISH uri| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(10) 200 OK| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(11) 通知してください。| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |(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までの要求も転送する許可を受取人に求めることができます。 これはこのフレームワークが登録証明書に備えるつもりである粒状のタイプです。 入って来る要求が、よりすばらしい粒状でどう扱われるかを(9:00と11:00の間にユーザAからの例えば要求を受け入れるだけです)定義したがっているユーザはCall Processing Language(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]で説明されるように同じ接続を使用しているユーザエージェントが以前に示されるようにこのセクションで説明されたメカニズムを使用する必要はないことに注意してください。
Rosenberg, et al. Standards Track [Page 24] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[24ページ]。
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 Identityを使用できません、アイデンティティであると断言されたPかSIPが、ユーザエージェントが登録される翻訳の受取人URIであるURI(例えば、一口: user@192.0.2.1 )の所有者であると記録係に立証するためにメカニズムを読みこなします。 この場合、リターンroutabilityを使用しなければなりません。
5.11. Relays Generating Traffic towards Recipients
5.11. 受取人に向かってトラフィックを生成するリレー
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.
受取人に向かってトラフィックを生成するリレーは、それらの受取人がそれらがいつでも与えた許容を取り消すことができるのを確実にする必要があります。 Trigger-同意は、これを達成するのを助けます。
5.11.1. Relay's Behavior
5.11.1. リレーの振舞い
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に、SHOULDがTrigger-同意ヘッダーフィールドを加えるという要求を要求に送ることを伴う翻訳を実行するリレー。 Trigger-同意ヘッダーフィールドにおける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.
リレーが以前にTrigger-同意ヘッダーフィールドに置いたURIに扱われたPUBLISH要求を受け取ると、リレーSHOULDは許可ドキュメントがある対応する受取人URIにMESSAGE要求を送ります。 したがって、リレーは、それが翻訳の受取人URIでTrigger-同意ヘッダーフィールドに置くURIを関連させることができる必要があります。
5.11.2. Definition of the Trigger-Consent Header Field
5.11.2. 引き金同意ヘッダーフィールドの定義
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].
↓これはTrigger-同意ヘッダーフィールドの増大しているBN記法(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引き金のまやかし仕様)引き金が仕様をだましている=(SIPS SIP-URI/ユリ)*(SEMI引き金-param)引き金-paramは「目標-uri」EQUAL LDQUOT*(引用されたqdtext/組の)ジェネリック目標-uri/param目標-uri=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-同意ヘッダーフィールドに関する例です:
Trigger-Consent: sip:123@relay.example.com
;target-uri="sip:friends@relay.example.com"
引き金同意: ちびちび飲んでください: 123@relay.example.com 、目標-uriは「一口: friends@relay.example.com 」と等しいです。
Rosenberg, et al. Standards Track [Page 25] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[25ページ]。
6. IANA Considerations
6. IANA問題
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ヘッダーフィールドパラメタを示しました。
6.1. Registration of the 470 Response Code
6.1. 470応答コードの登録
IANA has added the following new response code to the Methods and Response Codes subregistry under the SIP Parameters registry.
IANAはSIP Parameters登録の下のMethodsとResponse Codes subregistryに以下の新しい応答コードを加えました。
Response Code Number: 470
Default Reason Phrase: Consent Needed
Reference: [RFC5360]
応答コード番号: 470デフォルト理由句: 同意は参照を必要としました: [RFC5360]
6.2. Registration of the Trigger-Consent Header Field
6.2. 引き金同意ヘッダーフィールドの登録
IANA has added the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.
IANAはSIP Parameters登録の下のHeaderフィールズ副登録に以下の新しいSIPヘッダーフィールドを加えました。
Header Name: Trigger-Consent
Compact Form: (none)
Reference: [RFC5360]
ヘッダー名: 引き金同意コンパクト形: (なにも) 参照: [RFC5360]
6.3. Registration of the Permission-Missing Header Field
6.3. 許可をなくなったヘッダーフィールドの登録
IANA has added the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.
IANAはSIP Parameters登録の下のHeaderフィールズ副登録に以下の新しいSIPヘッダーフィールドを加えました。
Header Name: Permission-Missing
Compact Form: (none)
Reference: [RFC5360]
ヘッダー名: 許可をなくなったコンパクト形: (なにも) 参照: [RFC5360]
6.4. Registration of the target-uri Header Field Parameter
6.4. 目標-uri Header Field Parameterの登録
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 Parameters登録の中のHeader Field ParametersとParameter Values subregistryの下に'目標-uri'Trigger-同意ヘッダーフィールドパラメタを示しました:
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Trigger-Consent target-uri No [RFC5360]
事前に定義されたヘッダーフィールドパラメタ名は参照を評価します。---------------------------- --------------- --------- --------- 引き金同意目標-uriノー[RFC5360]
Rosenberg, et al. Standards Track [Page 26] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[26ページ]。
7. Security Considerations
7. セキュリティ問題
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.
登録して、記録係からトラフィックを受けるのに[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を指摘するので、リターンroutabilityテストが許容を承諾するか、または否定している受取人を認証するのに使用されるとき、許容を承諾するか、または否定するのに使用されるURIは、攻撃者から保護される必要があります。 SIPS URIは、この必要条件を満たすために[RFC5361]で説明されるように良いツールを提供します。 店とフォワードサーバが使用されているとき、ユーザエージェントとその店とフォワードサーバとのインタフェースは頻繁にSIPに基づいていません。 このような場合には、それらのURIを保証するのにSIPSを使用できません。 店とフォワードサーバの実装はメカニズムを配送するのに暗号化されていた状態で提供しなければなりません、そして、保全は彼らのユーザエージェントにメッセージを保護しました。
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.
Pending Additionsイベントパッケージによって提供された情報は機密である場合があります。 この理由で、[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.
許可ドキュメントは機密情報を明らかにすることができます。 攻撃者は、クライアントが彼らが与えるか、または否定していると思うものと異なった許容を承諾するか、または否定するのを持つように彼らを変更するのを試みるかもしれません。 この理由で、許可ドキュメントをクライアントに送るとき、リレーが情報保全保護と秘密性に強い手段を使用するのは、RECOMMENDEDです。
Rosenberg, et al. Standards Track [Page 27] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[27ページ]。
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.
情報が秘密にSHOULDが保全を保証するクライアントに情報を伝達するのに使用されるメカニズム。 SHOULD、[RFC3261]で説明されるように終わりから終わりへのSIP暗号化メカニズムの、そして、S/MIMEとしてそのようなこれらを達成してください。使用されます。
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.
終わりから終わりへのセキュリティ強い手段(such as above)が利用可能でないなら、ホップごとの[RFC3261]で説明されるようにTLSとSIPS URIに基づくセキュリティが使用されているのは、RECOMMENDEDです。
8. Acknowledgments
8. 承認
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、ジョン・ピーターソン、およびCullenジョニングスはこのドキュメントに関する役に立つ考えを提供しました。 ベン・キャンベル、交流Mahendran、キースDrage、およびメアリ・バーンズはこのドキュメントの徹底的なレビューを実行しました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」RFC3428(2002年12月)。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
エド[RFC5234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[RFC5361] Camarillo, G., "A Document Format for Requesting Consent",
RFC 5361, October 2008.
[RFC5361] 2008年10月のキャマリロ、G.、「同意を要求するためのドキュメント・フォーマット」RFC5361。
[RFC5362] Camarillo, G., "The Session Initiation Protocol (SIP)
Pending Additions Event Package", RFC 5362, October 2008.
[RFC5362]キャマリロ、G.、「セッション開始プロトコル(一口)未定の追加イベントパッケージ」、RFC5362、2008年10月。
Rosenberg, et al. Standards Track [Page 28] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[28ページ]。
[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.ローチ、「セッション開始のためのフレームワークとセキュリティ問題はURIリストサービスについて議定書の中で述べ(ちびちび飲みます)」、RFC5363、2008年10月。
9.2. Informative References
9.2. 有益な参照
[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.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、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)に処理に電話をしてください」 「インターネット電話サービスのユーザコントロールのための言語」、RFC3880、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.ウィリス、「セッション開始における同意ベースのコミュニケーションのための要件は(一口)について議定書の中で述べます」、RFC4453、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.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ(J.、「拡張マークアップ言語(XML)構成アクセス・プロトコル(XCAP)」RFC4825)は2007がそうするかもしれません。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]ローゼンバーグ(J.、「リソースリストを表すための拡張マークアップ言語(XML)形式」、RFC4826)は2007がそうするかもしれません。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5039] ローゼンバーグ、J.、C.ジョニングス、および「セッション開始プロトコル(一口)とスパム」、RFC5039、1月2008日
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
Work in Progress, June 2007.
[外国行き]のジョニングス、C.、およびR.マーイ、「クライアントを管理すると、セッション開始プロトコル(一口)のコネクションズは開始しました」、処理中の作業、2007年6月。
Rosenberg, et al. Standards Track [Page 29] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[29ページ]。
Authors' Addresses
作者のアドレス
Jonathan Rosenberg Cisco Iselin, NJ 08830 USA
ジョナサンローゼンバーグシスコのニュージャージー08830イーゼリン(米国)
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・キャマリロ(エディタ)エリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Dean Willis Unaffiliated 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
ディーン・ウィリス・属しない3100独立Pkwyテキサス75075#311-164プラノ(米国)
EMail: dean.willis@softarmor.com
メール: dean.willis@softarmor.com
Rosenberg, et al. Standards Track [Page 30] RFC 5360 Consent Framework October 2008
ローゼンバーグ、他 規格は同意フレームワーク2008年10月にRFC5360を追跡します[30ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Rosenberg, et al. Standards Track [Page 31]
ローゼンバーグ、他 標準化過程[31ページ]
一覧
スポンサーリンク
