[要約] RFC 4976は、MSRP（Message Sessions Relay Protocol）のリレー拡張に関する規格であり、MSRPセッションのリレーをサポートするための機能を提供します。目的は、MSRPメッセージのリレーを効率的かつ信頼性の高い方法で行うことです。
Network Working Group C. Jennings
Request for Comments: 4976 Cisco Systems, Inc.
Category: Standards Track R. Mahy
Plantronics
A. B. Roach
Estacado Systems
September 2007
Relay Extensions for the Message Session Relay Protocol (MSRP)
メッセージセッションリレープロトコル（MSRP）のリレー拡張機能
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
概要
Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.
インスタントメッセージを伝えるための2つの別々のモデルが定義されています。ページモードメッセージは独立しており、セッション開始プロトコル（SIP）セッションの一部ではありませんが、セッションモードメッセージはSIPを使用したセッションの一部として設定されます。メッセージセッションリレープロトコル（MSRP）は、SIPなどの個別のランデブープロトコルを使用してシグナルを使用するように設計された、仲介者のないバイナリコンテンツのほぼリアルタイムのピアツーピア交換のプロトコルです。このドキュメントでは、メッセージリレー仲介業者の概念をMSRPに紹介し、それらを使用するために必要な拡張機能について説明します。
Table of Contents
目次
1. Introduction and Requirements ...................................3
2. Conventions and Definitions .....................................4
3. Protocol Overview ...............................................4
3.1. Authorization Overview ....................................11
4. New Protocol Elements ..........................................11
4.1. The AUTH Method ...........................................11
4.2. The Use-Path Header .......................................12
4.3. The HTTP Authentication "WWW-Authenticate" Header .........12
4.4. The HTTP Authentication "Authorization" Header ............12
4.5. The HTTP Authentication "Authentication-Info" Header ......12
4.6. Time-Related Headers ......................................12
5. Client Behavior ................................................13
5.1. Connecting to Relays Acting on Your Behalf ................13
5.2. Sending Requests ..........................................18
5.3. Receiving Requests ........................................18
5.4. Managing Connections ......................................18
6. Relay Behavior .................................................18
6.1. Handling Incoming Connections .............................18
6.2. Generic Request Behavior ..................................19
6.3. Receiving AUTH Requests ...................................19
6.4. Forwarding ................................................20
6.4.1. Forwarding SEND Requests ...........................21
6.4.2. Forwarding Non-SEND Requests .......................22
6.4.3. Handling Responses .................................22
6.5. Managing Connections ......................................23
7. Formal Syntax ..................................................23
8. Finding MSRP Relays ............................................24
9. Security Considerations ........................................25
9.1. Using HTTP Authentication .................................25
9.2. Using TLS .................................................26
9.3. Threat Model ..............................................27
9.4. Security Mechanism ........................................29
10. IANA Considerations ...........................................31
10.1. New MSRP Method ..........................................31
10.2. New MSRP Headers .........................................31
10.3. New MSRP Response Codes ..................................31
11. Example SDP with Multiple Hops ................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
Appendix A. Implementation Considerations ........................34
There are a number of scenarios in which using a separate protocol for bulk messaging is desirable. In particular, there is a need to handle a sequence of messages as a session of media initiated using SIP [8], just like any other media type. The Message Session Relay Protocol (MSRP) [11] is used to convey a session of messages directly between two end systems with no intermediaries. With MSRP, messages can be arbitrarily large and all traffic is sent over reliable, congestion-safe transports.
バルクメッセージングに個別のプロトコルを使用することが望ましいシナリオがいくつかあります。特に、他のメディアタイプと同様に、SIP [8]を使用して開始されたメディアのセッションとして、一連のメッセージを処理する必要があります。メッセージセッションリレープロトコル（MSRP）[11]は、仲介者のない2つのエンドシステム間で直接メッセージのセッションを伝えるために使用されます。MSRPを使用すると、メッセージは任意に大きくなり、すべてのトラフィックが信頼できる渋滞に安全なトランスポートを介して送信されます。
This document describes extensions to the core MSRP protocol to introduce intermediaries called relays. With these extensions, MSRP clients can communicate directly, or through an arbitrary number of relays. Each client is responsible for identifying any relays acting on its behalf and providing appropriate credentials. Clients that can receive new TCP connections directly do not have to implement any new functionality to work with these relays.
このドキュメントでは、コアMSRPプロトコルへの拡張機能について説明して、リレーと呼ばれる仲介者を紹介します。これらの拡張機能を使用すると、MSRPクライアントは直接通信するか、任意の数のリレーを介して通信できます。各クライアントは、リレーに代わって作用するリレーを特定し、適切な資格情報を提供する責任があります。新しいTCP接続を直接受信できるクライアントは、これらのリレーで動作するために新しい機能を実装する必要はありません。
The goals of the MSRP relay extensions are listed below:
MSRPリレーエクステンションの目標を以下に示します。
o convey arbitrary binary MIME data without modification or transfer encoding
o 変更や転送エンコードなしで任意のバイナリMIMEデータを伝える
o continue to support client-to-client operation (no relay servers required)
o クライアントからクライアントへの操作を引き続きサポートします（リレーサーバーは必要ありません）
o operate through an arbitrary number of relays for policy enforcement
o 政策執行のために任意の数のリレーを介して動作する
o operate through relays under differing administrative control
o 異なる管理制御の下でリレーを介して動作します
o allow each client to control which relays are traversed on its behalf
o 各クライアントが、どのリレーが横断されているかを制御できるようにします
o prevent unsolicited messages (spam), "open relays", and Denial of Service (DoS) amplification
o 未承諾メッセージ（スパム）、「オープンリレー」、およびサービス拒否（DOS）増幅を防ぐ
o allow relays to use one or a small number of TCP or TLS [2] connections to carry messages for multiple sessions, recipients, and senders
o リレーが1つまたは少数のTCPまたはTLS [2]接続を使用して、複数のセッション、受信者、および送信者にメッセージを伝達することを許可します
o allow large messages to be sent over slow connections without causing head-of-line blocking problems
o 頭の遮断の問題を引き起こすことなく、遅い接続で大きなメッセージを送信できるようにする
o allow transmissions of large messages to be interrupted and resumed in places where network connectivity is lost and later reestablished
o ネットワーク接続が失われ、後で再確立される場所で大きなメッセージの送信を中断して再開できるようにします
o offer notification of message failure at any intermediary
o どの仲介者でもメッセージ障害の通知を提供します
o allow relays to delete state after a short amount of time
o 短時間後にリレーを削除することを許可します
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 [9].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [9]に記載されているように解釈される。
Below we list several definitions important to MSRP:
以下にMSRPにとって重要ないくつかの定義をリストします。
MSRP node: a host that implements the MSRP protocols as a client or a relay.
MSRPノード：MSRPプロトコルをクライアントまたはリレーとして実装するホスト。
MSRP client: an MSRP node that is the initial sender or final target of messages and delivery status.
MSRPクライアント：メッセージと配信ステータスの初期送信者または最終ターゲットであるMSRPノード。
MSRP relay: an MSRP node that forwards messages and delivery status and may provide policy enforcement. Relays can fragment and reassemble portions of messages.
MSRPリレー：メッセージと配信ステータスを転送し、ポリシー施行を提供するMSRPノード。リレーは、メッセージの一部を断片化し、再組み立てすることができます。
Message: arbitrary MIME [13][14] content that one client wishes to send to another. For the purposes of this specification, a complete MIME body as opposed to a portion of a complete message.
メッセージ：あるクライアントが別のクライアントに送信したいコンテンツ[13] [14]コンテンツ。この仕様の目的のために、完全なメッセージの一部とは対照的に、完全なmimeボディ。
chunk: a portion of a complete message delivered in a SEND request.
Chunk：送信リクエストで配信される完全なメッセージの一部。
end-to-end: delivery of data from the initiating client to the final target client.
エンドツーエンド：開始クライアントから最終ターゲットクライアントへのデータの配信。
hop: delivery of data between one MSRP node and an adjacent node.
ホップ：1つのMSRPノードと隣接するノード間でデータの配信。
With the introduction of this extension, MSRP has the concept of both clients and relays. Clients send messages to relays and/or other clients. Relays forward messages and message delivery status to clients and other relays. Clients that can open TCP connections to each other without intervening policy restrictions can communicate directly with each other. Clients who are behind firewalls or who need to use intermediaries for policy reasons can use the services of a relay. Each client is responsible for enlisting the assistance of one or more relays for its side of the communication.
この拡張機能の導入により、MSRPにはクライアントとリレーの両方の概念があります。クライアントは、リレーや他のクライアントにメッセージを送信します。リレーは、クライアントやその他のリレーへのフォワードメッセージとメッセージ配信ステータス。介入することなく互いにTCP接続を開くことができるクライアントは、互いに直接通信することができます。ファイアウォールの背後にいる、または政策上の理由で仲介者を使用する必要があるクライアントは、リレーのサービスを使用できます。各クライアントは、通信側の1つ以上のリレーの支援を採用する責任があります。
Clients that use a relay operate by first opening a TLS connection with a relay, authenticating, and retrieving an msrps: URI (from the relay) that the client can provide to its peers to receive messages later. There are several steps for doing this. First, the client opens a TLS connection to its first relay, and verifies that the name in the certificate matches the name of the relay to which it is trying to connect. Such verification is performed according to the procedures defined in Section 9.2. After verifying that it has connected to the proper host, the client authenticates itself to the relay using an AUTH request containing appropriate authentication credentials. In a successful AUTH response, the relay provides an msrps: URI associated with the path back to the client. The client can then give this URI to other clients for end-to-end message delivery.
リレーを使用するクライアントは、リレーとのTLS接続を最初に開いて動作し、MSRP：URI（リレーから）を認証し、取得します。これを行うためのいくつかの手順があります。最初に、クライアントは最初のリレーへのTLS接続を開き、証明書の名前が接続しようとしているリレーの名前と一致することを確認します。このような検証は、セクション9.2で定義されている手順に従って実行されます。適切なホストに接続されていることを確認した後、クライアントは、適切な認証資格情報を含む認証要求を使用してリレーに認証されます。成功した認証応答では、リレーはクライアントに戻るパスに関連付けられたMSRP：URIを提供します。クライアントは、エンドツーエンドのメッセージ配信のためにこのURIを他のクライアントに提供できます。
When clients wish to send a short message, they issue a SEND request with the entire contents of the message. If any relays are required, they are included in the To-Path header. The leftmost URI in the To-Path header is the next hop to deliver a request or response. The rightmost URI in the To-Path header is the final target.
クライアントが短いメッセージを送信したい場合、メッセージのコンテンツ全体で送信リクエストを発行します。リレーが必要な場合は、トーパスヘッダーに含まれています。To-Pathヘッダーの左端のURIは、リクエストまたは応答を提供する次のホップです。To-Pathヘッダーの右端のURIが最終ターゲットです。
SEND requests contain headers that indicate how they are acknowledged in a hop-by-hop form and in an end-to-end form. The default is that SEND messages are acknowledged hop-by-hop. (Each relay that receives a SEND request acknowledges receipt of the request before forwarding the content to the next relay or the final target.) All other requests are acknowledged end-to-end.
送信リクエストには、ホップバイホップ形式およびエンドツーエンドの形式でどのように認められているかを示すヘッダーが含まれています。デフォルトは、送信メッセージがホップバイホップに確認されることです。（送信リクエストを受信する各リレーは、コンテンツを次のリレーまたは最終ターゲットに転送する前に、リクエストの受信を確認します。）他のすべてのリクエストは、エンドツーエンドで確認されます。
With the introduction of relays, the subtle semantics of the To-Path header and the From-Path header become more relevant. The To-Path in both requests and responses is the list of URIs that need to be visited in order to reach the final target of the request or response. The From-Path is the list of URIs that indicate how to get back to the original sender of the request or response. These headers differ from the To and From headers in SIP, which do not "swap" from request to response. (Note that sometimes a request is sent to or from an intermediary directly.)
リレーの導入により、トーパスヘッダーとパスフロートヘッダーの微妙なセマンティクスがより関連性のあるものになります。リクエストと応答の両方のパスは、リクエストまたは応答の最終目標に到達するために訪問する必要があるURIのリストです。Pathからは、リクエストまたは応答の元の送信者に戻る方法を示すURIのリストです。これらのヘッダーは、SIPのヘッダーとの間とは異なりますが、リクエストから応答まで「交換」しません。（時々、リクエストが仲介者と直接送信されることに注意してください。）
When a relay forwards a request, it removes its address from the To-Path header and inserts it as the first URI in the From-Path header. For example, if the path from Alice to Bob is through relays A and B, when B receives the request it contains path headers that look like the following. (Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response.)
リレーがリクエストを転送すると、To-Pathヘッダーからアドレスを削除し、Path Headerの最初のURIとして挿入します。たとえば、アリスからボブへのパスがリレーAとBを使用している場合、Bがリクエストを受信すると、次のようなパスヘッダーが含まれます。（MSRPはラインの折りたたみを許可していないことに注意してください。この例の「\」は、このドキュメントのライン長の制限による線の継続を示しています。バックスラッシュも追加のCRLFも実際の要求または応答に含まれていません。）
To-Path: msrps://B.example.com/bbb;tcp \
msrps://Bob.example.com/bob;tcp
From-Path: msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
After forwarding the request, the path headers look like this:
リクエストを転送した後、パスヘッダーは次のようになります。
To-Path: msrps://Bob.example.com/bob;tcp
From-Path: msrps://B.example.com/bbb;tcp \
msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
The sending of an acknowledgment for SEND requests is controlled by the Success-Report and Failure-Report headers and works the same way as in the base MSRP protocol. When a relay receives a SEND request, if the Failure-Report is set to "yes", it means that the previous hop is running a timer and the relay needs to send a response to the request. If the final response conveys an error, the previous hop is responsible for constructing the error report and sending it back to the original sender of the message. The 200 response acknowledges receipt of the request so that the previous hop knows that it is no longer responsible for the request. If the relay knows that it will not be able to deliver the request and the Failure-Report is set to any value other than "no", then it sends a REPORT to tell the sender about the error. If the Failure-Report is set to "yes", then after the relay is done sending the request to the next hop it starts running a timer; if the timer expires before a response is received from the next hop, the relay assumes that an error has happened and sends a REPORT to the sender. If the Failure-Report is not set to "yes", there is no need for the relay to run this timer.
送信リクエストの承認の送信は、成功レポートと失敗レポートヘッダーによって制御され、ベースMSRPプロトコルと同じように機能します。リレーが送信要求を受信した場合、故障レポートが「はい」に設定されている場合、以前のホップがタイマーを実行し、リレーはリクエストに応答を送信する必要があります。最終的な応答がエラーを伝える場合、前のホップはエラーレポートを構築し、メッセージの元の送信者に送信する責任があります。200の応答は、リクエストの受領を認めているため、前のホップがリクエストの責任がなくなったことを知っています。リレーがリクエストを配信できないことを知っていて、故障レポートが「いいえ」以外の値に設定されている場合、エラーについて送信者に伝えるためのレポートを送信します。故障レポートが「はい」に設定されている場合、リレーが終了した後、リクエストを次のホップに送信して、タイマーの実行を開始します。次のホップから応答が受信される前にタイマーが期限切れになった場合、リレーはエラーが発生したと想定し、レポートを送信者に送信します。故障レポートが「はい」に設定されていない場合、このタイマーを実行するリレーは必要ありません。
The following example shows a typical MSRP session. The AUTH requests are explained in a later section but left in the example for call flow completeness.
次の例は、典型的なMSRPセッションを示しています。認証要求については、後のセクションで説明しますが、コールフローの完全性の例に残ります。
Alice a.example.org b.example.net Bob
| | | |
|::::::::::::::::::::>| connection opened |<::::::::::::::::::::|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 200 OK-----------| |--- 200 OK---------->|
| | | |
.... time passes ....
| | | |
|--- SEND ----------->| | |
|<-- 200 OK ----------|:::::::::::::::::::>| (slow link) |
| |--- SEND ---------->| |
| |<-- 200 OK ---------|--- SEND ----------->|
| | | ....>|
| | | ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT ----------|
| |<-- REPORT ---------| |
|<-- REPORT ----------| | |
| | | |
The SEND and REPORT messages are shown below to illustrate the To-Path and From-Path headers. (Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash, nor the extra CRLF is included in the actual request or response.)
送信およびレポートメッセージを以下に示します。（MSRPはラインの折りたたみを許可していないことに注意してください。例の「\」は、このドキュメントのライン長の制限による線の継続を示しています。バックスラッシュも追加のCRLFも実際の要求または応答に含まれていません。）
MSRP 6aef SEND
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp
Message-ID: 87652
-------6aef$
MSRP juh76 SEND
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------juh76$
MSRP juh76 200 OK
To-Path: msrps://a.example.org:9000/kjfjan;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp
Message-ID: 87652
-------juh76$
MSRP xght6 SEND
To-Path: msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------xght6$
MSRP xght6 200 OK
To-Path: msrps://b.example.net:9000/aeiug;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
MSRP yh67 REPORT
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
When sending large content, the client may split up a message into smaller pieces; each SEND request might contain only a portion of the complete message. For example, when Alice sends Bob a 4-GB file called "file.mpeg", she sends several SEND requests each with a portion of the complete message. Relays can repack message fragments en route. As individual parts of the complete message arrive at the final destination client, the receiving client can optionally send REPORT requests indicating delivery status.
大規模なコンテンツを送信すると、クライアントはメッセージを小さなピースに分割する場合があります。各送信要求には、完全なメッセージの一部のみが含まれる場合があります。たとえば、アリスが「file.mpeg」と呼ばれる4 gbファイルをボブに送信すると、完全なメッセージの一部を含むいくつかの送信要求を送信します。リレーは、途中でメッセージフラグメントを再パックできます。完全なメッセージの個々の部分が最終的な宛先クライアントに到着すると、受信クライアントはオプションで配信ステータスを示すレポートリクエストを送信できます。
MSRP nodes can send individual portions of a complete message in multiple SEND requests. As relays receive chunks, they can reassemble or re-fragment them as long as they resend the resulting chunks in order. (Receivers still need to be prepared to receive out-of-order chunks, however.) If the sender has set the Success-Report header to "yes", once a chunk or complete message arrives at the destination client, the destination will send a REPORT request indicating that a chunk arrived end-to-end. This request travels back along the reverse path of the SEND request. Unlike the SEND request, which can be acknowledged along every hop, REPORT requests are never acknowledged.
MSRPノードは、複数の送信要求で完全なメッセージの個々の部分を送信できます。リレーがチャンクを受けると、結果のチャンクを順番に再度再送信する限り、それらを再組み立てまたは再燃させることができます。（ただし、受信者は、オーダーアウトのチャンクを受け取る準備をする必要があります。）送信者が成功レポートヘッダーを「はい」に設定した場合、宛先クライアントにチャンクまたは完全なメッセージが届くと、宛先は送信されますチャンクがエンドツーエンドで到着したことを示すレポートリクエスト。このリクエストは、送信要求の逆パスに沿って移動します。すべてのホップに沿って確認できる送信要求とは異なり、レポートリクエストは認められません。
The following example shows a message being re-chunked through two relays:
次の例は、2つのリレーを通して再チャンキングされているメッセージを示しています。
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 1-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 1-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 1-3 ------|
| |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 1-3 ------| | ...>|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
Relays only keep transaction states for a short time for each chunk. Delivery over each hop should take no more than 30 seconds after the last byte of data is sent. Client applications define their own implementation-dependent timers for end-to-end message delivery.
リレーは、チャンクごとに短時間トランザクション状態のみを保持します。各ホップを介した配信は、データの最後のバイトが送信されてから30秒以内にかかる必要があります。クライアントアプリケーションは、エンドツーエンドのメッセージ配信のために、独自の実装依存タイマーを定義します。
For client-to-client communication, the sender of a message typically opens a new TCP connection (with or without TLS) if one is needed. Relays reuse existing connections first, but can open new connections (typically to other relays) to deliver requests such as SEND or REPORT. Responses can only be sent over existing connections.
クライアント間通信の場合、メッセージの送信者は通常、必要な場合に新しいTCP接続（TLSの有無にかかわらず）を開きます。リレー既存の接続を最初に再利用しますが、新しい接続（通常は他のリレーに）を開き、送信やレポートなどのリクエストを配信できます。応答は、既存の接続に対してのみ送信できます。
The relationship between MSRP and signaling protocols (such as SIP) is unchanged by this document, and is as described in [11]. An example of an SDP exchange for an MSRP session involving relays is shown in Section 11.
MSRPとシグナル伝達プロトコル（SIPなど）の関係は、このドキュメントで変更されておらず、[11]に記載されているとおりです。リレーを含むMSRPセッションのSDP交換の例をセクション11に示します。
A key element of this protocol is that it cannot introduce open relays, with all the associated problems they create, including DoS attacks. A message is only forwarded by a relay if it is either going to or coming from a client that has authenticated to the relay and been authorized for relaying messages on that particular session. Because of this, clients use an AUTH message to authenticate to a relay and get a URI that can be used for forwarding messages.
このプロトコルの重要な要素は、DOS攻撃を含むすべての関連する問題があるオープンリレーを導入できないことです。メッセージは、リレーがリレーに認証され、その特定のセッションでメッセージをリレーすることを許可されているクライアントに行くか、または由来する場合にのみ転送されます。このため、クライアントはAUTHメッセージを使用してリレーに認証し、メッセージを転送するために使用できるURIを取得します。
If a client wishes to use a relay, it sends an AUTH request to the relay. The client authenticates the relay using the relay's TLS certificate. The client uses HTTP Digest authentication [1] to authenticate to the relay. When the authentication succeeds, the relay returns a 200 response that contains the URI that the client can use in the MSRP path for the relay.
クライアントがリレーの使用を希望する場合、リレーに認証要求を送信します。クライアントは、リレーのTLS証明書を使用してリレーを認証します。クライアントは、HTTP Digest Authentication [1]を使用してリレーに認証します。認証が成功すると、リレーは、クライアントがリレーのMSRPパスで使用できるURIを含む200の応答を返します。
A typical challenge response flow is shown below:
典型的なチャレンジ応答フローを以下に示します。
Alice a.example.org
| |
|::::::::::::::::::::>|
|--- AUTH ----------->|
|<- 401 Unauthorized -|
|--- AUTH ----------->|
|<-- 200 OK-----------|
| |
The URI that the client should use is returned in the Use-Path header of the 200.
クライアントが使用すべきURIは、200の使用パスヘッダーで返されます。
Note that URIs returned to the client are effectively secret tokens that should be shared only with the other MSRP client in a session. For that reason, the client MUST NOT reuse the same URI for multiple sessions, and needs to protect these URIs from eavesdropping.
クライアントに戻ったURISは、セッションで他のMSRPクライアントとのみ共有する必要がある秘密のトークンであることに注意してください。そのため、クライアントは複数のセッションに対して同じURIを再利用してはならず、これらのURIを盗聴から保護する必要があります。
AUTH requests are used by clients to create a handle they can use to receive incoming requests. AUTH requests also contain credentials used to authenticate a client and authorization policy used to block Denial of Service attacks.
認証要求は、クライアントが着信リクエストを受信するために使用できるハンドルを作成するために使用されます。AUTHリクエストには、クライアントの認証に使用される資格情報も含まれており、サービス拒否攻撃をブロックするために使用される承認ポリシーが含まれています。
In response to an AUTH request, a successful response contains a Use-Path header with a list of URIs that the client can give to its peers to route responses back to the client.
AUTHリクエストに応じて、成功した応答には、クライアントがピアに提供してクライアントに戻ることができるURIのリストを備えた使用パスヘッダーが含まれています。
The Use-Path header is a list of URIs provided by an MSRP relay in response to a successful AUTH request. This list of URIs can be used by the MSRP client that sent the AUTH request to receive MSRP requests and to advertise this list of URIs, for example, in a session description. URIs in the Use-Path header MUST include a fully qualified domain name (as opposed to a numeric IP address) and an explicit port number.
使用パスヘッダーは、成功した認証要求に応じてMSRPリレーによって提供されるURIのリストです。このURIのリストは、MSRPリクエストを送信したMSRPクライアントがMSRPリクエストを受信し、このURIのリストをセッションの説明で宣伝するために使用できます。使用パスヘッダーのurisには、完全に適格なドメイン名（数値IPアドレスとは対照的に）と明示的なポート番号を含める必要があります。
The URIs in the Use-Path header are in the same order that the authenticating client uses them in a To-Path header. Instructions on forming To-Path headers and SDP [7] path attributes from information in the Use-Path header are provided in Section 5.1.
使用パスヘッダーのurisは、認証するクライアントがトーパスヘッダーでそれらを使用するのと同じ順序であります。使用パスヘッダーの情報からのパスヘッダーとSDP [7]パス属性の形成に関する指示は、セクション5.1に記載されています。
The "WWW-Authenticate" header contains a challenge token used in the HTTP Digest authentication procedure (from RFC 2617 [1]). The usage of HTTP Digest authentication in MSRP is described in detail in Section 5.1.
「www-authenticate」ヘッダーには、HTTPダイジェスト認証手順（RFC 2617 [1]から）で使用されるチャレンジトークンが含まれています。MSRPでのHTTPダイジェスト認証の使用については、セクション5.1で詳しく説明しています。
The "Authorization" header contains authentication credentials for HTTP Digest authentication (from RFC 2617 [1]). The usage of HTTP Digest authentication in MSRP is described in detail in Section 5.1.
「承認」ヘッダーには、HTTPダイジェスト認証の認証資格情報が含まれています（RFC 2617 [1]から）。MSRPでのHTTPダイジェスト認証の使用については、セクション5.1で詳しく説明しています。
The "Authentication-Info" header contains future challenges to be used for HTTP Digest authentication (from RFC 2617 [1]). The usage of HTTP Digest authentication in MSRP is described in detail in Section 5.1.
「Authentication-info」ヘッダーには、HTTPダイジェスト認証に使用される将来の課題が含まれています（RFC 2617 [1]）。MSRPでのHTTPダイジェスト認証の使用については、セクション5.1で詳しく説明しています。
The Expires header in a request provides a relative time after which the action implied by the method of the request is no longer of interest. In a request, the Expires header indicates how long the sender would like the request to remain valid. In a response, the Expires header indicates how long the responder considers this information relevant. Specifically, an Expires header in an AUTH request indicates how long the provided URIs will be valid.
リクエストのヘッダーの有効期限は相対的な時間を提供し、その後、リクエストの方法によって暗示されるアクションはもはや関心がありません。リクエストでは、有効期限がヘッダーが送信者がリクエストを有効に保つ時間を示します。応答では、有効期限がヘッダーが応答者がこの情報を関連する期間と見なす時間を示します。具体的には、認証要求のヘッダーの有効期限は、提供されたURIが有効になる期間を示します。
The Min-Expires header contains the minimum duration a server will permit in an Expires header. It is sent only in 423 "Interval Out-of-Bounds" responses. Likewise, the Max-Expires header contains the maximum duration a server will permit in an Expires header.
Min-Expiresヘッダーには、サーバーが有効期限に許可する最小期間が含まれています。423の「間隔外」応答でのみ送信されます。同様に、MAX-Expiresヘッダーには、サーバーが許可する最大期間が有効期限になります。
Clients that want to use the services of a relay or list of relays need to send an AUTH request to each relay that will act on their behalf. (For example, some organizations could deploy an "intra-org" relay and an "extra-org" relay.) The inner relay is used to tunnel the AUTH requests to the outer relay. For example, the client will send an AUTH to intra-org and get back a path that can be used for forwarding through intra-org. The client would then send a second AUTH destined to extra-org but sent through intra-org. The intra-org relay forwards this to extra-org and extra-org returns a path that can be used to forward messages from another destination to extra-org to intra-org and then on to this client. Each relay authenticates the client. The client authenticates the first relay and each relay authenticates the next relay.
リレーまたはリレーのリストのサービスを使用したいクライアントは、それぞれに代わって行動する各リレーに認証要求を送信する必要があります。（たとえば、一部の組織は、「内部ORG」リレーと「エクストラオルグ」リレーを展開できます。）内側のリレーを使用して、認証要求を外部リレーにトンネルします。たとえば、クライアントはAUTHをORG内に送信し、ORG内の転送に使用できるパスを取り戻します。クライアントは、Extra-ORGに運命づけられているが、ORG内を介して送信される2番目の認証を送信します。ORG内リレーはこれをExtra ORGに転送し、ORG Extra-ORGは、別の目的地からExtra-ORG、およびこのクライアントにメッセージを転送するために使用できるパスを返します。各リレーはクライアントを認証します。クライアントは最初のリレーを認証し、各リレーは次のリレーを認証します。
Clients can be configured (typically, through discovery or manual provisioning) with a list of relays they need to use. They MUST be able to form a connection to the first relay and send an AUTH command to get a URI that can be used in a To-Path header. The client can authenticate its first relay by looking at the relay's TLS certificate. The client MUST authenticate itself to each of its relays using HTTP Digest authentication [1] (see Section 9.1 for details).
クライアントは、使用する必要があるリレーのリストを使用して（通常、発見または手動プロビジョニングを通じて）構成できます。最初のリレーへの接続を形成し、authコマンドを送信して、トーパスヘッダーで使用できるURIを取得できる必要があります。クライアントは、リレーのTLS証明書を調べることで、最初のリレーを認証できます。クライアントは、HTTP Digest認証[1]を使用して、各リレーに認証する必要があります（詳細については、セクション9.1を参照）。
The relay returns a URI, or list of URIs, in the "Use-Path" header of a success response. Each URI SHOULD be used for only one unique session. These URIs are used by the client in the path attribute that is sent in the SDP to set up the session, and in the To-Path header of outgoing requests. To form the To-Path header for outgoing requests, the client takes the list of URIs in the Use-Path header after the outermost authentication and appends the list of URIs provided in the path attribute in the peer's session description. To form the SDP path attribute to provide to the peer, the client reverses the list of URIs in the Use-Path header (after the outermost authentication), and appends the client's own URI.
リレーは、成功応答の「使用パス」ヘッダーでURIまたはURIのリストを返します。各URIは、1つの一意のセッションにのみ使用する必要があります。これらのURIは、セッションをセットアップするためにSDPで送信されるパス属性のクライアントによって使用され、発信リクエストのパスヘッダーで使用されます。発信リクエストのためにTo-Pathヘッダーを形成するために、クライアントは最も外側の認証後に使用パスヘッダーのURIのリストを取得し、ピアのセッションの説明のパス属性に提供されるURIのリストを追加します。SDPパス属性を形成してピアに提供するために、クライアントは（最も外側の認証の後）に使用パスヘッダーのURIのリストを逆にし、クライアント自身のURIを追加します。
For example, "A" has to traverse its own relays "B" and "C", and then relays "D" and "E" in domain2 to reach "F". Client "A" will authenticate with its relays "B" and "C" and eventually receive a Use-Path header containing "B C". Client "A" reverses the list (now "C B") and appends its own URI (now "C B A"), and provides this list to "F" in a path SDP attribute. Client "F" sends its SDP path list "D E F", which client "A" appends to the Use-Path list it received "B C". The resulting To-Path header is "B C D E F".
たとえば、「A」は独自のリレー「B」と「C」を通過し、「D」と「E」をDOMAIN2でリレーして「F」に到達する必要があります。クライアント「A」は、リレー「B」と「C」で認証され、最終的に「B C」を含む使用パスヘッダーを受け取ります。クライアント「A」はリスト（現在「C B」）を逆転させ、独自のURI（現在「C B A」）を追加し、パスSDP属性の「F」にこのリストを提供します。クライアント「F」はSDPパスリスト「D e f」を送信します。クライアントは、「B C」を受け取った使用パスリストに「A」を追加します。結果のトゥパスヘッダーは「b c d e f」です。
domain 1 domain 2
---------------- -----------------
client relays relays client
A ----- B -- C -------- D -- E ----- F
Use-Path returned by C: B C
path: attribute generated by A: C B A
path: attribute received from F: D E F
To-Path header generated by A: B C D E F
The initial AUTH request sent to a relay by a client will generally not contain an Authorization header, since the client has no challenge to which it can respond. In response to an AUTH request that does not contain an Authorization header, a relay MUST respond with a "401 Unauthorized" response containing a WWW-Authenticate header. The WWW-Authenticate header is formed as described in RFC 2617 [1], with the restrictions and modifications described in Section 9.1. The realm chosen by the MSRP relay in such a challenge is a matter of administrative policy. Because a single relay does not have multiple protection spaces in MSRP, it is not unreasonable to always use the relay's hostname as the realm.
クライアントが応答できる課題がないため、クライアントからリレーに送信された最初の認証要求には、一般に認可ヘッダーが含まれていません。承認ヘッダーを含まない認証要求に応じて、リレーはwww-authenticateヘッダーを含む「401不正な」応答で応答する必要があります。www-authenticateヘッダーは、RFC 2617 [1]に記載されているように形成され、セクション9.1で説明されている制限と変更があります。このような課題でMSRPリレーによって選択された領域は、管理ポリシーの問題です。単一のリレーにはMSRPに複数の保護スペースがないため、リレーのホスト名を常に領域として使用することは不合理ではありません。
Upon receiving a 401 response to a request, the client SHOULD fetch the realm from the WWW-Authenticate header in the response and retry the request, including an Authorization header with the correct credentials for the realm. The Authorization header is formed as described in RFC 2617 [1], with the restrictions and modifications described in Section 9.1.
リクエストに対する401の応答を受信すると、クライアントは、応答のwww-authenticateヘッダーから領域を取得し、領域の正しい資格情報を持つ承認ヘッダーを含むリクエストを再試行する必要があります。認証ヘッダーは、RFC 2617 [1]に記載されているように形成され、セクション9.1で説明されている制限と変更があります。
When a client wishes to use more than one relay, it MUST send an AUTH request to each relay it wishes to use. Consider a client A, that wishes messages to flow from A to the first relay, R1, then on to a second relay, R2. This client will do a normal AUTH with R1. It will then do an AUTH transaction with R2 that is routed through R1. The client will form this AUTH message by setting the To-Path to msrps://R1;tcp msrps://R2;tcp. R1 will forward this request onward to R2.
クライアントが複数のリレーを使用したい場合、使用したい各リレーに認証要求を送信する必要があります。クライアントAを考えてみましょう。クライアントAは、メッセージから最初のリレー、R1に流れ、次に2番目のリレー、R2に流れることを望みます。このクライアントは、R1で通常の認証を行います。その後、R1を介してルーティングされるR2で認証トランザクションを行います。クライアントは、to-pathをmsrps：// r1; tcp msrps：// r2; tcpに設定することにより、この認証メッセージを形成します。R1はこのリクエストをR2に転送します。
When sending an AUTH request, the client MAY add an Expires header to request a MSRP URI that is valid for no longer than the provided interval (a whole number of seconds). The server will include an Expires header in a successful response indicating how long its URI from the Use-Path will be valid. Note that each server can return an independent expiration time.
AUTHリクエストを送信すると、クライアントはヘッダーの有効期限を追加して、提供された間隔（秒数）以下で有効なMSRP URIを要求する場合があります。サーバーには、使用パスからのURIが有効になる期間を示す、成功した応答で有効期限のあるヘッダーが含まれます。各サーバーは、独立した有効期限を返すことができることに注意してください。
Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual request or response.
MSRPはラインの折りたたみを許可しないことに注意してください。この例の「\」は、このドキュメントのライン長の制限による線の継続を示しています。バックスラッシュも追加のCRLFも、実際の要求または応答に含まれていません。
(Alice opens a TLS connection to intra.example.com and sends an AUTH request to initiate the authentication process.)
（AliceはIntra.example.comへのTLS接続を開き、認証プロセスを開始するための認証要求を送信します。）
MSRP 49fh AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------49fh$
(Alice's relay challenges the AUTH request.)
（アリスのリレーは認証要求に挑戦します。）
MSRP 49fh 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
-------49fh$
(Alice responds to the challenge.)
（アリスは挑戦に応答します。）
MSRP 49fi AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="intra.example.com", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
qop=auth, nc=00000001, cnonce="0a4f113b", \
response="6629fae49393a05397450978507c4ef1"
-------49fi$
(Alice's relay confirms that Alice is an authorized user. As a matter of local policy, it includes an "Authentication-Info" header with a new nonce value to expedite future AUTH requests.)
（アリスのリレーは、アリスが承認されたユーザーであることを確認しています。ローカルポリシーの問題として、将来の認証要求を促進するための新しいNONCE値を持つ「認証-INFO」ヘッダーが含まれています。）
MSRP 49fi 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp
Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\
rspauth="7327570c586207eca2afae94fc20903d", \
cnonce="0a4f113b", nc=00000001, qop=auth
Expires: 900
-------49fi$
(Alice now sends an AUTH request to her "external" relay through her "internal" relay, using the URI she just obtained; the AUTH request is challenged.)
（アリスは、彼女が取得したばかりのURIを使用して、彼女の「外部」リレーに「外部」リレーに認証要求を送信します。認証要求に挑戦されます。）
MSRP mnbvw AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------mnbvw$
MSRP m2nbvw AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
-------m2nbvw$
MSRP m2nbvw 401 Unauthorized
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------m2nbvw$
MSRP mnbvw 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------mnbvw$
(Alice replies to the challenge with her credentials and is then authorized to use the "external" relay).
（アリスは、資格情報で課題に返信し、その後、「外部」リレーを使用することを許可されます）。
MSRP m3nbvx AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m3nbvx$
MSRP m4nbvx AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m4nbvx$
MSRP m4nbvx 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m4nbvx$
MSRP m3nbvx 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m3nbvx$
The procedure for forming SEND and REPORT requests is identical for clients whether or not relays are involved. The specific procedures are described in Section 7 of the core MSRP protocol.
送信およびレポートリクエストを形成する手順は、リレーが関係するかどうかにかかわらずクライアントにとって同一です。特定の手順は、Core MSRPプロトコルのセクション7で説明されています。
As usual, once the next-hop URI is determined, the client MUST find the appropriate address, port, and transport to use and then check if there is already a suitable existing connection to the next-hop target. If so, the client MUST send the request over the most suitable connection. Suitability MAY be determined by a variety of factors such as measured load and local policy, but in most simple implementations a connection will be suitable if it exists and is active.
いつものように、次のホップURIが決定されると、クライアントは使用するための適切なアドレス、ポート、およびトランスポートを見つけてから、次のホップターゲットに既に適切な既存の接続があるかどうかを確認する必要があります。その場合、クライアントは最も適切な接続でリクエストを送信する必要があります。適合性は、測定された負荷やローカルポリシーなどのさまざまな要因によって決定される場合がありますが、ほとんどの単純な実装では、存在してアクティブな場合は接続が適しています。
The procedure for receiving requests is identical for clients whether or not relays are involved.
リクエストを受信する手順は、リレーが関係するかどうかにかかわらずクライアントにとって同一です。
Clients should open a connection whenever they wish to deliver a request and no suitable connection exists. For connections to relays, the client should leave a connection up until no sessions have used it for a locally defined period of time, which defaults to 5 minutes for foreign relays and one hour for the client's relays.
クライアントは、リクエストを配信したい場合はいつでも接続を開く必要があり、適切な接続が存在しません。リレーへの接続の場合、クライアントは、セッションがローカルで定義された期間それを使用しないまで接続を残す必要があります。
When a relay receives an incoming connection on a port configured for TLS, it includes a client CertificateRequest in the same record in which it sends its ServerHello. If the TLS client provides a certificate, the server verifies it and continues if the certificate is valid and rooted in a trusted authority. If the TLS client does not provide a certificate, the server assumes that the client is an MSRP endpoint and invokes Digest authentication. Once a TCP or TLS channel is negotiated, the server waits for up to 30 seconds to receive an MSRP request over the channel. If no request is received in that time, the server closes the connection. If no successful requests are sent during this probationary period, the server closes the connection. Likewise, if several unsuccessful requests are sent during the probation period and no requests are sent successfully, the server SHOULD close the connection.
リレーがTLS用に構成されたポートで着信接続を受信すると、ServerHelloを送信するのと同じレコードにクライアントの証明書が含まれます。TLSクライアントが証明書を提供する場合、サーバーはそれを検証し、証明書が有効であり、信頼できる当局に根ざしている場合に継続します。TLSクライアントが証明書を提供しない場合、サーバーはクライアントがMSRPエンドポイントであると想定し、消化認証を呼び出します。TCPまたはTLSチャネルがネゴシエートされると、サーバーはチャネル上でMSRPリクエストを受信するために最大30秒間待機します。その間にリクエストが受信されない場合、サーバーは接続を閉じます。この保護観察期間中に成功した要求が送信されない場合、サーバーは接続を閉じます。同様に、保護観察期間中にいくつかの失敗した要求が送信され、リクエストが正常に送信されない場合、サーバーは接続を閉じる必要があります。
Upon receiving a new request, relays first verify the validity of the request. Relays then examine the first URI in the To-Path header and remove this URI if it matches a URI corresponding to the relay. If the request is not addressed to the relay, the relay immediately drops the corresponding connection over which the request was received.
新しいリクエストを受信したら、リレーは最初にリクエストの有効性を検証します。その後、リレーはトゥパスヘッダーの最初のURIを調べ、リレーに対応するURIと一致する場合はこのURIを削除します。要求がリレーに宛てられていない場合、リレーはすぐにリクエストが受信された対応する接続をドロップします。
When a relay receives an AUTH request, the first thing it does is to authenticate and authorize the previous hop and the client at the far end. If there are no other relays between this relay and the client, then these are the same thing.
リレーが認証要求を受信した場合、最初に行うことは、ファーエンドで以前のホップとクライアントを認証および承認することです。このリレーとクライアントの間に他のリレーがない場合、これらは同じものです。
When the previous hop is a relay, authentication is done with TLS using mutual authentication. If the TLS client presented a host certificate, the relay checks that the subjectAltName in the certificate of the TLS client matches the hostname in the first From-Path URI. If the TLS client doesn't provide a host certificate, the relay assumes the TLS client is an MSRP client and sends it a challenge.
前のホップがリレーの場合、相互認証を使用してTLSで認証が行われます。TLSクライアントがホスト証明書を提示した場合、リレーは、TLSクライアントの証明書のsubjectaltnameが最初のFrom-Path URIのホスト名と一致することをチェックします。TLSクライアントがホスト証明書を提供しない場合、リレーはTLSクライアントがMSRPクライアントであると想定し、課題を送信します。
Authorization is a matter of local policy at the relay. Many relays will choose to authorize all relays that can be authenticated, possibly in conjunction with a blacklisting mechanism. Relays intended to operate only within a limited federation may choose to authorize only those relays whose identity appears in a provisioned list. Other authorization policies may also be applied.
許可は、リレーのローカルポリシーの問題です。多くのリレーは、おそらくブラックリストメカニズムと組み合わせて、認証できるすべてのリレーを承認することを選択します。限られた連邦内でのみ動作することを目的としたリレーは、プロビジョニングリストにIDが表示されるリレーのみを承認することを選択できます。その他の認可ポリシーも適用される場合があります。
When the previous hop is a client, the previous hop is the same as the identity of the client. The relay checks the credentials (username and password) provided by the client in the Authorization header and checks if this client is allowed to use the relay. If the client is not authorized, the relay returns a 403 response. If the client has requested a particular expiration time in an Expires header, the relay needs to check that the time is acceptable to it and, if not, return an error containing a Min-Expires or Max-Expires header, as appropriate.
前のホップがクライアントである場合、前のホップはクライアントのIDと同じです。リレーは、クライアントが承認ヘッダーで提供する資格情報（ユーザー名とパスワード）をチェックし、このクライアントがリレーの使用を許可されているかどうかを確認します。クライアントが承認されていない場合、リレーは403の応答を返します。クライアントがヘッダーの有効期限のある有効期限を要求した場合、リレーは時間が許容されていることを確認し、必要に応じて最小expiresまたはMax-Expiresヘッダーを含むエラーを返す必要があります。
Next the relay will generate an MSRP URI that allows messages to be forwarded to or from this previous hop. If the previous hop was a relay authenticated by mutual TLS, then the URI MUST be valid to route across any connection the relay has to the previous hop relay. If the previous hop is a client, then the URI MUST only be valid to route across the same connection over which the AUTH request was received. If the client's connection is closed and then reopened, the URI MUST be invalidated.
次に、リレーは、この以前のホップにメッセージを転送できるようにするMSRP URIを生成します。前のホップが相互TLSによって認証されたリレーである場合、URIはリレーが以前のホップリレーに持っている任意の接続を横切るために有効でなければなりません。前のホップがクライアントである場合、URIは、認証要求が受信されたのと同じ接続を横切るためにのみ有効でなければなりません。クライアントの接続が閉じてから再開された場合、URIを無効にする必要があります。
If the AUTH request contains an Expires header, the relay MUST ensure that the URI is invalidated after the expiry time. The URI MUST contain at least 64 bits of cryptographically random material so that it is not guessable by attackers. If a relay is requested to forward a message for which the URI is not valid, the relay MUST discard the message and MAY send a REPORT indicating that the AUTH URI was bad.
認証要求に有効期限が含まれている場合、リレーは、有効期限が切れた後にURIが無効になることを確認する必要があります。URIには、攻撃者が推測できないように、少なくとも64ビットの暗号化的にランダムな材料を含める必要があります。URIが有効でないメッセージを転送するリレーが要求された場合、リレーはメッセージを破棄し、認証URIが悪いことを示すレポートを送信する必要があります。
A successful AUTH response returns a Use-Path header that contains an MSRP URI that the client can use. It also returns an Expires header that indicates how long the URI will be valid (expressed as a whole number of seconds).
成功した認証応答は、クライアントが使用できるMSRP URIを含む使用パスヘッダーを返します。また、URIが有効になる期間を示すヘッダーの有効期限を返します（秒数として表されます）。
If a relay receives several unsuccessful AUTH requests from a client that is directly connected to it via TLS, the relay SHOULD terminate the corresponding connection. Similarly, if a relay forwards several failed AUTH requests to the same destination that originate from a client that is directly connected to it via TLS, the relay SHOULD terminate the corresponding connection. Determination of a remote AUTH failure can be made by observing an AUTH request containing an Authorization header that triggers a 401 response without a "stale=TRUE" indication. These preventive measures apply only to a connection between a relay and a client; a relay SHOULD NOT use excessive AUTH request failures as a reason to terminate a connection with another relay.
リレーがTLSを介して直接接続されているクライアントからいくつかの失敗した認証要求を受信した場合、リレーは対応する接続を終了する必要があります。同様に、リレーがTLSを介して直接接続されているクライアントから発生する同じ宛先にリレーを転送する場合、リレーは対応する接続を終了する必要があります。リモート認証障害の決定は、「古い=真」の表示なしで401の応答をトリガーする認証ヘッダーを含む認証要求を観察することによって行うことができます。これらの予防措置は、リレーとクライアントの間の接続にのみ適用されます。リレーは、別のリレーとの接続を終了する理由として、過度の認証要求障害を使用しないでください。
Before any request is forwarded, the relay MUST check that the first URI in the To-Path header corresponds to a URI that this relay has created and handed out in the Use-Path header of an AUTH request. Next it verifies that either 1) the next hop is the next hop back toward the client that obtained this URI, or 2) the previous hop was the correct previous hop coming from the client that obtained this URI.
リクエストが転送される前に、リレーは、To-Pathヘッダーの最初のURIが、このリレーが作成したURIに対応していることを確認する必要があります。次に、1）次のホップは、このURIを取得したクライアントへの次のホップであるか、2）前のホップは、このURIを取得したクライアントからの正しい以前のホップであることを確認します。
Since transact-id values are not allowed to conflict on a given connection, a relay will generally need to construct a new transact-id value for any request that it forwards.
Transact-ID値は特定の接続で競合することは許可されていないため、リレーは一般に、転送するリクエストに対して新しいTransact-ID値を構築する必要があります。
If an incoming SEND request contains a Failure-Report header with a value of "yes", an MSRP relay that receives that SEND request MUST respond with a final response immediately. A 200-class response indicates the successful receipt of a message fragment but does not mean that the message has been forwarded on to the next hop. The final response to the SEND MUST be sent only to the previous hop, which could be an MSRP relay or the original sender of the SEND request.
着信送信リクエストに「はい」の値を持つ失敗レポートヘッダーが含まれている場合、その送信要求を受信するMSRPリレーは、すぐに最終応答で応答する必要があります。200クラスの応答は、メッセージフラグメントの受領が成功したことを示しますが、メッセージが次のホップに転送されたことを意味しません。送信に対する最終的な応答は、MSRPリレーまたは送信要求の元の送信者である可能性がある前のホップにのみ送信する必要があります。
If the Failure-Report header is "yes", then the relay MUST run a timer to detect if transmission to the next hop fails. The timer starts when the last byte of the message has been sent to the next hop. If after 30 seconds the next hop has not sent any response, then the relay MUST construct a REPORT with a status code of 408 to indicate a timeout error happened sending the message, and send the REPORT to the original sender of the message.
故障レポートヘッダーが「はい」の場合、リレーはタイマーを実行して、次のホップへの送信が失敗した場合に検出する必要があります。タイマーは、メッセージの最後のバイトが次のホップに送信されたときに起動します。30秒後に次のホップが応答を送信しなかった場合、リレーは408のステータスコードを含むレポートを作成して、メッセージを送信するタイムアウトエラーが発生し、メッセージの元の送信者にレポートを送信する必要があります。
If the Failure-Report header is "yes" or "partial", and if there is a problem processing the SEND request or if an error response is received for that SEND request, then the relay MUST respond with an appropriate error response in a REPORT back to the original source of the message.
故障レポートヘッダーが「はい」または「部分的」である場合、および送信要求の処理に問題がある場合、またはその送信要求に対してエラー応答が受信された場合、リレーはレポートの適切なエラー応答で応答する必要がありますメッセージの元のソースに戻ります。
The MSRP relay MAY further break up the message fragment received in the SEND request into smaller fragments and forward them to the next hop in separate SEND requests. It MAY also combine message fragments received before or after this SEND request, and forward them out in a single SEND request to the next hop identified in the To-Path header. The MSRP relay MUST NOT combine message fragments from SEND requests with different values in the Message-ID header.
MSRPリレーは、送信要求で受信したメッセージフラグメントをより小さなフラグメントにさらに分割し、個別の送信要求で次のホップに転送する場合があります。また、この送信リクエストの前または後に受信したメッセージフラグメントを組み合わせて、To-Pathヘッダーで識別された次のホップに1回の送信リクエストでそれらを転送する場合があります。MSRPリレーは、メッセージ-IDヘッダーに異なる値を持つ送信要求からのメッセージフラグメントを結合してはなりません。
The MSRP relay MAY choose whether to further fragment the message, or combine message fragments, or send the message as is, based on some policy that is administered, or based on the network speed to the next hop, or any other mechanism.
MSRPリレーは、メッセージをさらに断片化するか、メッセージフラグメントを組み合わせたり、そのようにメッセージを送信したりするかどうかを選択する場合があります。
If the MSRP relay has knowledge of the byte range that it will transmit to the next hop, it SHOULD update the Byte-Range header in the SEND request appropriately.
MSRPリレーに次のホップに送信されるバイト範囲の知識がある場合、送信要求のバイト範囲ヘッダーを適切に更新する必要があります。
Before forwarding the SEND request to the next hop, the MSRP relay MUST inspect the first URI in the To-Path header. If it indicates this relay, the relay removes this URI from the To-Path header and inserts this URI in the From-Path header before any other URIs. If it does not indicate this relay, there has been an error in forwarding at a previous hop. In this case, the relay SHOULD discard the message, and if the Failure-Report header is set to "yes", the relay SHOULD generate a failure report.
送信リクエストを次のホップに転送する前に、MSRPリレーはTo-Pathヘッダーの最初のURIを検査する必要があります。このリレーを示している場合、リレーはこのURIをTo-Pathヘッダーから削除し、他のURIの前にこのURIをPath Headerに挿入します。このリレーを示していない場合、以前のホップでの転送にエラーがありました。この場合、リレーはメッセージを破棄し、故障レポートヘッダーが「はい」に設定されている場合、リレーは障害レポートを生成するはずです。
An MSRP relay that receives any request other than a SEND request (including new methods unknown to the relay) first follows the validation and authorization rules for all requests. Then the relay moves its URI from the beginning of the To-Path headers to the beginning of the From-Path header and forwards the request on to the next hop. If it already has a connection to the next hop, it SHOULD use this connection and not form a new connection. If no suitable connection exists, the relay opens a new connection.
送信要求以外のリクエスト（リレーに不明な新しい方法を含む）以外のリクエストを受信するMSRPリレーは、最初にすべてのリクエストの検証および承認ルールに従います。次に、リレーはURIをトーパスヘッダーの開始からFrom-Pathヘッダーの開始まで移動し、リクエストを次のホップに転送します。次のホップへの接続が既にある場合は、この接続を使用して、新しい接続を形成する必要はありません。適切な接続が存在しない場合、リレーは新しい接続を開きます。
Requests with an unknown method are forwarded as if they were REPORT requests. An MSRP node MAY be configured to block unknown methods for security reasons.
未知の方法を持つリクエストは、レポートリクエストであるかのように転送されます。MSRPノードは、セキュリティ上の理由で未知の方法をブロックするように構成できます。
Relays receiving a response first verify that the first URI in the To-Path corresponds to itself; if not, the response SHOULD be dropped. Likewise, if the message cannot be parsed, the relay MUST drop the response. Next the relay determines if there are additional URIs in the To-Path. (For responses to SEND requests there will be no additional URIs, whereas responses to AUTH requests have additional URIs directing the response back to the client.)
応答を受信するリレーは、最初にパスの最初のURIがそれ自体に対応していることを確認します。そうでない場合は、応答を削除する必要があります。同様に、メッセージを解析できない場合、リレーは応答をドロップする必要があります。次に、リレーは、トーパスに追加のurisがあるかどうかを決定します。（リクエストを送信するための回答については、追加のURIはありませんが、認証要求への応答には、クライアントに応答を指示する追加のURIがあります。）
If the response matches an existing transaction, then that transaction is completed and any timers running on it can be removed. If the response is a non 200 response, and the original request was a SEND request that had a Failure-Report header with a value other than "no", then the relay MUST send a REPORT indicating the nature of the failure. The response code received by the relay is used to form the status line in the REPORT that the relay sends.
応答が既存のトランザクションと一致する場合、そのトランザクションが完了し、その上で実行されているタイマーは削除できます。応答が200以外の応答であり、元のリクエストが「いいえ」以外の値を持つ失敗レポートヘッダーを備えた送信要求である場合、リレーは障害の性質を示すレポートを送信する必要があります。リレーで受信した応答コードは、リレーが送信するレポートのステータスラインを形成するために使用されます。
If there are additional URIs in the To-Path header, the relay MUST then move its URI from the To-Path header, insert its URI in front of any other URIs in the From-Path header, and forward the response to the next URI in the To-Path header. The relay sends the request over the best connection that corresponds to the next URI in the To-Path header. If this connection has closed, then the response is silently discarded.
To-Pathヘッダーに追加のURIがある場合、リレーはURIをTo-Pathヘッダーから移動し、From Pathヘッダーの他のURIの前にURIを挿入し、次のURIへの応答を転送する必要がありますトーパスヘッダー。リレーは、トゥパスヘッダーの次のURIに対応する最良の接続でリクエストを送信します。この接続が閉じた場合、応答は静かに破棄されます。
Relays should keep connections open as long as possible. If a connection has not been used in a significant time (more than one hour), it MAY be closed. If the relay runs out of resources and can no longer establish new connections, it SHOULD start closing existing connections. It MAY choose to close the connections based on a least recently used basis.
リレーは、できるだけ長く接続を開いたままにする必要があります。接続がかなりの時間（1時間以上）に使用されていない場合、閉じられる可能性があります。リレーがリソースを使い果たし、新しい接続を確立できなくなった場合、既存の接続を閉じ始めるはずです。最近使用されていないベースに基づいて接続を閉じることを選択できます。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 4234 [10].
; This ABNF imports all the definitions in the ABNF of RFC 4975.
;このABNFは、RFC 4975のABNFのすべての定義をインポートします。
header =/ Expires / Min-Expires / Max-Expires / Use-Path /
WWW-Authenticate / Authorization / Authentication-Info
; this adds to the rule in RFC 4975
mAUTH = %x41.55.54.48 ; AUTH in caps
method =/ mAUTH
; this adds to the rule in RFC 4975
WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP digest-param
*("," SP digest-param)
digest-param = ( realm / nonce / [ opaque ] / [ stale ] / [
algorithm ] / qop-options / [auth-param] )
realm = "realm=" realm-value realm-value = quoted-string
Realm = "Realm =" Realm-Value Realm-Value = Quoted-string
auth-param = token "=" ( token / quoted-string )
nonce = "nonce=" nonce-value
nonce-value = quoted-string
opaque = "opaque=" quoted-string
stale = "stale=" ( "true" / "false" )
algorithm = "algorithm=" ( "MD5" / token )
qop-options = "qop=" DQUOTE qop-list DQUOTE
qop-list = qop-value *( "," qop-value )
qop-value = "auth" / token
Authorization = "Authorization:" SP credentials
承認= "承認：" SP資格情報
credentials = "Digest" SP digest-response *( "," SP digest-response)
資格情報= "Digest" SP Digest-Response *（ "、" SP Digest-Response）
digest-response = ( username / realm / nonce / response / [
algorithm ] / cnonce / [opaque] / message-qop /
[nonce-count] / [auth-param] )
username = "username=" username-value
username-value = quoted-string
message-qop = "qop=" qop-value
cnonce = "cnonce=" cnonce-value
cnonce-value = nonce-value
nonce-count = "nc=" nc-value
nc-value = 8LHEX
response = "response=" request-digest
request-digest = DQUOTE 32LHEX DQUOTE
LHEX = DIGIT / %x61-66 ;lowercase a-f
Authentication-Info = "Authentication-Info:" SP ainfo
*("," ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce=" nonce-value
response-auth = "rspauth=" response-digest
response-digest = DQUOTE *LHEX DQUOTE
Expires = "Expires:" SP 1*DIGIT
Min-Expires = "Min-Expires:" SP 1*DIGIT
Max-Expires = "Max-Expires:" SP 1*DIGIT
Use-Path = "Use-Path:" SP MSRP-URI *(SP MSRP-URI)
When resolving an MSRP URI that contains an explicit port number, an MSRP node follows the rules in Section 6 of the MSRP base specification. MSRP URIs exchanged in SDP and in To-Path and From-Path headers in non-AUTH requests MUST have an explicit port number. (The only message in this specification that can have an MSRP URI without an explicit port number is in the To-Path header in an AUTH request.) Similarly, if the authority component of an msrps: URI contains an IPv4 address or an IPv6 reference, a port number MUST be present.
明示的なポート番号を含むMSRP URIを解決する場合、MSRPノードはMSRPベース仕様のセクション6のルールに従います。MSRP URISは、SDPおよびTo-PathおよびFrom Pathヘッダーで非Authリクエストで交換され、明示的なポート番号が必要です。（明示的なポート番号なしでMSRP URIを持つことができるこの仕様の唯一のメッセージは、認証要求のトーパスヘッダーにあります。）同様に、MSRPS：URIにIPv4アドレスまたはIPv6リファレンスが含まれている場合、、ポート番号が存在する必要があります。
The following rules allow MSRP clients to discover MSRP relays more easily in AUTH requests. If the authority component contains a domain name and an explicit port number is provided, attempt to look up a valid address record (A or AAAA) for the domain name. Connect using TLS over the default transport (TCP) with the provided port number.
以下のルールにより、MSRPクライアントは、認証要求でMSRPリレーをより簡単に発見できます。機関コンポーネントにドメイン名が含まれており、明示的なポート番号が提供されている場合は、ドメイン名の有効なアドレスレコード（AまたはAAAA）を検索しようとします。提供されたポート番号でデフォルトのトランスポート（TCP）でTLSを使用して接続します。
If a domain name is provided but no port number, perform a DNS SRV [4] lookup for the '_msrps' service and '_tcp' transport at the domain name, and follow the Service Record (SRV) selection algorithm defined in that specification to select the entry. (An '_msrp' service is not defined, since AUTH requests are only sent over TLS.) If no SRVs are found, try an address lookup (A or AAAA) for the domain name. Connect using TLS over the default transport (TCP) with the default port number (2855). Note that AUTH requests MUST only be sent over a TLS-protected channel. An SRV lookup in the example.com domain might return:
ドメイン名が提供されているがポート番号がない場合は、ドメイン名で「_MSRPS」サービスと「_TCP」トランスポートをDNS SRV [4]検索を実行し、その仕様で定義されたサービスレコード（SRV）選択アルゴリズムに従ってください。エントリを選択します。（認証要求はTLSを介してのみ送信されるため、「_MSRP」サービスは定義されていません。）SRVが見つからない場合は、ドメイン名のアドレスルックアップ（AまたはAAAA）を試してください。デフォルトのポート番号（2855）でデフォルトのトランスポート（TCP）でTLSを使用して接続します。認証要求は、TLS保護されたチャネルを介してのみ送信する必要があることに注意してください。example.comドメインのSRV検索が返される場合があります。
;; in example.com. Pri Wght Port Target _msrps._tcp IN SRV 0 1 9000 server1.example.com. _msrps._tcp IN SRV 0 2 9000 server2.example.com.
;;example.comで。pri wghtポートターゲット_msrps._tcp in srv 0 1 9000 server1.example.com。_msrps._tcp in srv 0 2 9000 server2.example.com。
If implementing a relay farm, it is RECOMMENDED that each member of the relay farm have an SRV entry. If any members of the farm have multiple IP addresses (for example, an IPv4 and an IPv6 address), each of these addresses SHOULD be registered in DNS as separate A or AAAA records corresponding to a single target.
リレーファームを実装する場合は、リレーファームの各メンバーにSRVエントリを持つことをお勧めします。農場のメンバーが複数のIPアドレスを持っている場合（たとえば、IPv4やIPv6アドレス）、これらの各アドレスは、単一のターゲットに対応する別のAまたはAAAAレコードとしてDNSに登録する必要があります。
This section first describes the security mechanisms available for use in MSRP. Then the threat model is presented. Finally, we list implementation requirements related to security.
このセクションでは、最初にMSRPで使用できるセキュリティメカニズムについて説明します。次に、脅威モデルが提示されます。最後に、セキュリティに関連する実装要件をリストします。
AUTH requests MUST be authenticated. The authentication mechanism described in this specification uses HTTP Digest authentication. HTTP Digest authentication is performed as described in RFC 2617 [1], with the following restrictions and modifications:
認証要求は認証されている必要があります。この仕様で説明されている認証メカニズムは、HTTPダイジェスト認証を使用します。HTTPダイジェスト認証は、RFC 2617 [1]に記載されているように実行され、次の制限と修正があります。
o Clients MUST NOT attempt to use Basic authentication, and relays MUST NOT request or accept Basic authentication.
o クライアントは基本認証を使用しようとしてはなりません。また、リレーは基本認証を要求または受け入れてはなりません。
o The use of a qop value of auth-int makes no sense for MSRP. Integrity protection is provided by the use of TLS. Consequently, MSRP relays MUST NOT indicate a qop of auth-int in a challenge.
o auth-intのQOP値の使用は、MSRPには意味がありません。整合性保護は、TLSの使用によって提供されます。したがって、MSRPリレーは、課題でauth-intのQOPを示してはなりません。
o The interaction between the MD5-sess algorithm and the nextnonce mechanism is underspecified in RFC 2617 [1]; consequently, MSRP relays MUST NOT send challenges indicating the MD5-sess algorithm.
o MD5-SESSアルゴリズムとNextNonceメカニズムとの相互作用は、RFC 2617 [1]では不十分です。その結果、MSRPリレーは、MD5-SESSアルゴリズムを示す課題を送信してはなりません。
o Clients SHOULD consider the protection space within a realm to be scoped to the authority portion of the URI, without regard to the contents of the path portion of the URI. Accordingly, relays SHOULD NOT send the "domain" parameter on the "WWW-Authenticate" header, and clients MUST ignore it if present.
o クライアントは、URIのパス部分の内容に関係なく、URIの権限部分にスコープされる領域内の保護スペースを考慮する必要があります。したがって、リレーは「www-authenticate」ヘッダーに「ドメイン」パラメーターを送信するべきではなく、クライアントは存在する場合はそれを無視する必要があります。
o Clients and relays MUST include a qop parameter in all "WWW-Authenticate" and "Authorization" headers. Note that the value of the qop parameter in a "WWW-Authenticate" header is quoted, but the value of the qop parameter in an "Authorization" header or "Authentication-Info" header is not quoted.
o クライアントとリレーは、すべての「www-authenticate」および「承認」ヘッダーにQOPパラメーターを含める必要があります。「www-authenticate」ヘッダーのQOPパラメーターの値は引用されているが、「承認」ヘッダーまたは「認証-INFO」ヘッダーのQOPパラメーターの値は引用されていないことに注意してください。
o Clients MUST send cnonce and nonce-count parameters in all "Authorization" headers.
o クライアントは、すべての「承認」ヘッダーにCNONCEおよびNONCE-Countパラメーターを送信する必要があります。
o The request-URI to be used in calculating H(A2) is the rightmost URI in the To-Path header.
o H（A2）の計算で使用されるリクエスト-URIは、To-Pathヘッダーの右端のURIです。
o Relays MUST include rspauth, cnonce, nc, and qop parameters in a "Authentication-Info" header for all "200 OK" responses to an AUTH request.
o リレーには、認証要求に対するすべての「200 OK」応答の「認証INFO」ヘッダーに、NC、NC、およびQOPパラメーターを含める必要があります。
Note that the BNF in RFC 2617 has a number of errors. In particular, the value of the uri parameter MUST be in quotes; further, the parameters in the Authentication-Info header MUST be separated by commas. The BNF in this document is correct, as are the examples in RFC 2617 [1].
RFC 2617のBNFには多くのエラーがあることに注意してください。特に、URIパラメーターの値は引用符である必要があります。さらに、認証INFOヘッダーのパラメーターは、コンマで分離する必要があります。このドキュメントのBNFは、RFC 2617 [1]の例と同様に正しいです。
The use of the nextnonce and nc parameters is supported as described in RFC 2617 [1], which provides guidance on how and when they should be used. As a slight modification to the guidance provided in RFC 2617, implementors of relays should note that AUTH requests cannot be pipelined; consequently, there is no detrimental impact on throughput when relays use the nextnonce mechanism.
NextNonceおよびNCパラメーターの使用は、RFC 2617 [1]に記載されているようにサポートされています。これは、使用方法と使用方法に関するガイダンスを提供します。RFC 2617で提供されるガイダンスをわずかに変更するため、リレーの実装者は、認証要求をパイプ化できないことに注意する必要があります。その結果、リレーがNextNonceメカニズムを使用する場合、スループットに有害な影響はありません。
See Section 5.1 for further information on the procedures for client authentication.
クライアント認証手順の詳細については、セクション5.1を参照してください。
TLS is used to authenticate relays to senders and to provide integrity and confidentiality for the headers being transported. MSRP clients and relays MUST implement TLS. Clients MUST send the TLS ClientExtendedHello extended hello information for server name indication as described in RFC 4366 [5]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [6] MUST be supported (other cipher-suites MAY also be supported). A relay MUST act as a TLS server and present a certificate with its identity in the SubjectAltName using the choice type of dnsName. Relay-to-relay connections MUST use TLS with mutual authentication. Client-to-relay communications MUST use TLS for AUTH requests and responses.
TLSは、送信者にリレーを認証し、輸送中のヘッダーに完全性と機密性を提供するために使用されます。MSRPクライアントとリレーはTLSを実装する必要があります。クライアントは、RFC 4366 [5]に記載されているように、サーバー名表示のHello情報を拡張したTLSをTLSに送信する必要があります。TLS_RSA_WITH_AES_128_CBC_SHA [6]のTLS cipher-suiteをサポートする必要があります（他の暗号スイーツもサポートされる場合があります）。リレーはTLSサーバーとして機能し、dnsnameの選択タイプを使用してsubjectaltnameにそのIDを持つ証明書を提示する必要があります。リレー間接続は、相互認証でTLSを使用する必要があります。クライアント間通信は、認証要求と応答にTLSを使用する必要があります。
The SubjectAltName in the certificate received from a relay MUST match the hostname part of the URI, and the certificate MUST be valid according to RFC 3280 [12], including having a date that is valid and being signed by an acceptable certification authority. After validating that such is the case, the device that initiated the TLS connection can assume that it has connected to the correct relay.
リレーから受け取った証明書のsumbestaltnameは、URIのホスト名部分と一致する必要があり、証明書はRFC 3280 [12]に従って有効でなければなりません。そのようなことを検証した後、TLS接続を開始したデバイスは、正しいリレーに接続されていると想定できます。
This document does not define procedures for using mutual authentication between an MSRP client and an MSRP relay. Authentication of clients is handled using the AUTH method via the procedures described in Section 5.1 and Section 6.3. Other specifications may define the use of TLS mutual authentication for the purpose of authenticating users associated with MSRP clients. Unless operating under such other specifications, MSRP clients SHOULD present an empty certificate list (if one is requested by the MSRP relay), and MSRP relays SHOULD ignore any certificates presented by the client.
このドキュメントでは、MSRPクライアントとMSRPリレーの間で相互認証を使用する手順を定義しません。クライアントの認証は、セクション5.1およびセクション6.3で説明されている手順を介してAUTHメソッドを使用して処理されます。その他の仕様は、MSRPクライアントに関連付けられたユーザーを認証する目的で、TLS相互認証の使用を定義する場合があります。そのような他の仕様の下で操作しない限り、MSRPクライアントは空の証明書リストを提示する必要があります（MSRPリレーで要求されている場合）、MSRPリレーはクライアントが提示した証明書を無視する必要があります。
This behavior is defined specifically to allow forward-compatibility with specifications that define the use of TLS for client authentication.
この動作は、クライアント認証のためにTLSの使用を定義する仕様との順方向互換性を可能にするために特別に定義されます。
Note: When relays are involved in a session, TCP without TLS is only used when a user that does not use relays connects directly to the relay of a user that is using relays. In this case, the client has no way to authenticate the relay other than to use the URIs that form a shared secret in the same way those URIs are used when no relays are involved.
注：リレーがセッションに関与している場合、TLSのないTCPは、リレーを使用しないユーザーがリレーを使用しているユーザーのリレーに直接接続する場合にのみ使用されます。この場合、クライアントは、リレーが関係していない場合に使用されるのと同じように、共有秘密を形成するURIを使用する以外にリレーを認証する方法がありません。
This section discusses the threat model and the broad mechanism that needs to be in place to secure the protocol. The next section describes the details of how the protocol mechanism meets the broad requirements.
このセクションでは、脅威モデルと、プロトコルを保護するために整備される必要がある広範なメカニズムについて説明します。次のセクションでは、プロトコルメカニズムが幅広い要件をどのように満たしているかの詳細について説明します。
MSRP allows two peer-to-peer clients to exchange messages. Each peer can select a set of relays to perform certain policy operations for them. This combined set of relays is referred to as the route set. A channel outside of MSRP always needs to exist, such as out-of-band provisioning or an explicit rendezvous protocol such as SIP, that can securely negotiate setting up the MSRP session and communicate the route set to both clients. A client may trust a relay with certain types of routing and policy decisions, but it might or might not trust the relay with all the contents of the session. For example, a relay being trusted to look for viruses would probably need to be allowed to see all the contents of the session. A relay that helped deal with traversal of the ISP's Network Address Translator (NAT) would likely not be trusted with the contents of the session but would be trusted to correctly forward messages.
MSRPを使用すると、2人のピアツーピアクライアントがメッセージを交換できます。各ピアは、リレーのセットを選択して、特定のポリシー操作を実行できます。この結合されたリレーセットは、ルートセットと呼ばれます。MSRPの外側にあるチャネルは、帯域外プロビジョニングやSIPなどの明示的なランデブープロトコルなど、常に存在する必要があります。クライアントは、特定の種類のルーティングとポリシーの決定を含むリレーを信頼する場合がありますが、セッションのすべての内容を使用してリレーを信頼する場合と信頼していない場合があります。たとえば、ウイルスを探すと信頼されているリレーは、おそらくセッションのすべての内容を確認する必要があります。ISPのネットワークアドレス翻訳者（NAT）のトラバーサルに対処するのに役立ったリレーは、セッションの内容と信頼されていない可能性が高いが、メッセージを正しく転送すると信頼されます。
Clients implicitly trust the relays through which they send and receive messages to honor the routing indicated in those messages, within the constraints of the MSRP protocol. Clients also need to trust that the relays they use do not insert new messages on their behalf or modify messages sent to or by the clients. It is worth noting that some relays are in a position to cause a client to misroute a message by maliciously modifying a Use-Path returned by a relay further down the chain. However, this is not an additional security threat because these same relays can also decide to misroute a message in the first place. If the relay is trusted to route messages, it is reasonable to trust it not to tamper with the Use-Path header. If the relay cannot be trusted to route messages, then it cannot be used.
クライアントは、MSRPプロトコルの制約内で、これらのメッセージに示されているルーティングを尊重するために、メッセージを送信および受信するリレーを暗黙的に信頼しています。また、クライアントは、使用するリレーが彼らに代わって新しいメッセージを挿入したり、クライアントに送信されたり、クライアントから送信されたメッセージを変更したりしないことを信頼する必要があります。一部のリレーは、チェーンのさらに下にリレーによって返される使用パスを悪意を持って変更することにより、クライアントにメッセージを誤って誤って誘惑する立場にあることは注目に値します。ただし、これは追加のセキュリティの脅威ではありません。これらの同じリレーは、そもそもメッセージを誤解することも決定する可能性があるためです。リレーがメッセージをルーティングすると信頼されている場合、使用パスヘッダーを改ざんしないように信頼することは合理的です。リレーがメッセージをルーティングすることを信頼できない場合、使用することはできません。
Under certain circumstances, relays need to trust other relays not to modify information between them and the client they represent. For example, if a client is operating through Relay A to get to Relay B, and Relay B is logging messages sent by the client, Relay B may be required to authenticate that the messages they logged originate with the client, and have not been modified or forged by Relay A. This can be done by having the client sign the message.
特定の状況では、リレーは、他のリレーとそれらが表すクライアントとの間の情報を変更しないように信頼する必要があります。たとえば、クライアントがリレーAを介してリレーBに到達し、リレーBがクライアントによって送信されたメッセージのロギングである場合、リレーBがクライアントに発信され、変更されていないことを認証するためにリレーBが必要になる場合があります。またはリレーAによって偽造された。これは、クライアントにメッセージに署名させることで実行できます。
Clients need to be able to authenticate that the relay they are communicating with is the one they trust. Likewise, relays need to be able to authenticate that the client is the one they are authorized to forward information to. Clients need the option of ensuring that information between the relay and the client is integrity protected and confidential to elements other than the relays and clients. To simplify the number of options, traffic between relays is always integrity protected and encrypted regardless of whether or not the client requests it. There is no way for the clients to tell the relays what strength of cryptographic mechanisms to use between relays other than to have the clients choose relays that are administered to require an adequate level of security.
クライアントは、彼らが通信しているリレーが彼らが信頼するものであることを認証できる必要があります。同様に、リレーは、クライアントが情報を転送することを許可されているものであることを認証できる必要があります。クライアントは、リレーとクライアントの間の情報が整合性保護され、リレーとクライアント以外の要素に機密性があることを確認するオプションが必要です。オプションの数を簡素化するために、クライアントが要求するかどうかに関係なく、リレー間のトラフィックは常に保護および暗号化されます。クライアントが、適切なレベルのセキュリティを必要とするために管理されているリレーを選択する以外に、リレー間で使用する暗号化メカニズムの強度をリレーに伝える方法はありません。
The system also needs to stop messages from being directed to relays that are not supposed to see them. To keep the relays from being used in Denial of Service (DoS) attacks, the relays never forward messages unless they have a trust relationship with either the client sending or the client receiving the message; further, they only forward a message if it is coming from or going to the client with which they have the trust relationship. If a relay has a trust relationship with the client that is the destination of the message, it should not send the message anywhere except to the client that is the destination.
また、システムは、メッセージが表示されることは想定されていないリレーにメッセージが送信されるのを止める必要があります。リレーがサービス拒否（DOS）攻撃で使用されないようにするために、クライアントが送信またはクライアントがメッセージを受信する信頼関係がない限り、リレーはメッセージを転送することはありません。さらに、彼らはそれが信頼関係を持っているクライアントから来ているか、クライアントに行く場合にのみメッセージを転送します。リレーがメッセージの宛先であるクライアントとの信頼関係を持っている場合、宛先であるクライアント以外の場所にメッセージを送信してはなりません。
Some terminology used in this discussion: SClient is the client sending a message and RClient is the client receiving a message. SRelay is a relay the sender trusts and RRelay is a relay the receiver trusts. The message will go from SClient to SRelay1 to SRelay2 to RRelay2 to RRelay1 to RClient.
この議論で使用されているいくつかの用語：Sclientはメッセージを送信するクライアントであり、Rclientはメッセージを受信しているクライアントです。SRELAYは送信者の信託であり、RRELAYは受信機の信託がリレーです。このメッセージは、SCLIENTからSRELAY1、SRELAY2、RRELAY2、RRELAY1、RCLIANTに送信されます。
Confidentiality and privacy from elements not in the route set is provided by using TLS on all the transports. Relays always use TLS. A client can use unprotected TCP for peer-to-peer MSRP, but any time a client communicates with its relay, it MUST use TLS.
ルートセットにない要素からの機密性とプライバシーは、すべてのトランスポートでTLSを使用して提供されます。リレーは常にTLSを使用します。クライアントは、ピアツーピアMSRPに保護されていないTCPを使用できますが、クライアントがリレーと通信するときはいつでも、TLSを使用する必要があります。
The relays authenticate to the clients using TLS (but don't have to do mutual TLS). Further, the use of the rspauth parameter in the Authentication-Info header provides limited authentication of relays to which the client is not directly connected. The clients authenticate to the relays using HTTP Digest authentication. Relays authenticate to each other using TLS mutual authentication.
TLSを使用してクライアントに認証するリレー（ただし、相互のTLSを実行する必要はありません）。さらに、Authentication-infoヘッダーでRSPAuthパラメーターを使用すると、クライアントが直接接続されていないリレーの限られた認証が提供されます。クライアントは、HTTPダイジェスト認証を使用してリレーを認証します。TLS相互認証を使用して、互いに認証されます。
By using Secure/Multipurpose Internet Mail Extensions (S/MIME) [3] encryption, the clients can protect their actual message contents so that the relays cannot see the contents. End-to-end signing is also possible with S/MIME.
Secure/Multipurpose Internet Mail Extensions（S/MIME）[3]暗号化を使用することにより、クライアントは実際のメッセージコンテンツを保護して、リレーがコンテンツを見ることができないようにします。S/MIMEでは、エンドツーエンドの署名も可能です。
The complex part is making sure that relays cannot successfully be instructed to send messages to a place where they should not. This is done by having the client authenticate to the relay and having the relay return a token. Messages that contain this token can be relayed if they come from the client that got the token or if they are being forwarded towards the client that got the token. The tokens are the URIs that the relay places in the Use-Path header. The tokens contain random material (defined in Section 6.3) so that they are not guessable by attackers. The tokens need to be protected so they are only ever seen by elements in the route set or other elements that at least one of the parties trusts. If some third party discovers the token that RRelay2 uses to forward messages to RClient, then that third party can send as many messages as they want to RRelay2 and it will forward them to RClient. The third party cannot cause them to be forwarded anywhere except to RClient, eliminating the open relay problems. SRelay1 will not forward the message unless it contains a valid token.
複雑な部分は、リレーを正常に指示できないことを確認することです。これは、クライアントにリレーに認証し、リレーにトークンを返すことによって行われます。このトークンを含むメッセージは、トークンを取得したクライアントから来る場合、またはトークンを取得したクライアントに転送されている場合に中継することができます。トークンは、リレーが使用パスヘッダーに配置されているURIです。トークンには、攻撃者が推測できないように、ランダム材料（セクション6.3で定義）が含まれています。トークンは保護する必要があるため、ルートセットまたは少なくとも1つの当事者が信頼する他の要素の要素によってのみ見られます。一部のサードパーティがRRELAY2がRCLIENTに転送するために使用するトークンを発見した場合、サードパーティはRRELAY2に必要な数のメッセージを送信でき、RCLIANTに転送できます。サードパーティは、RClientを除くどこにでも転送されることはできず、オープンリレーの問題を排除します。SRELAY1は、有効なトークンが含まれていない限り、メッセージを転送しません。
When SClient goes to get a token from SRelay2, this request is relayed through SRelay1. SRelay2 authenticates that it really is SClient requesting the token, but it generates a token that is only valid for forwarding messages to or from SRelay1. SRelay2 knows it is connected to SRelay1 because of the mutual TLS.
SclientがSRELAY2からトークンを取得すると、この要求はSRELAY1を介して中継されます。SRELAY2は、実際にはトークンを要求していることを認証していますが、SRELAY1へのメッセージを転送するのにのみ有効なトークンを生成します。SRELAY2は、相互TLSのためにSRELAY1に接続されていることを知っています。
The tokens are carried in the resource portion of the MSRP URIs. The length of time the tokens are valid for is negotiated using the Expire header in the AUTH request. Clients need to re-negotiate the tokens using a new offer/answer [15] exchange (e.g., a SIP re-invite) before the tokens expire.
トークンは、MSRP URIのリソース部分に運ばれます。トークンが有効な時間の長さは、認証要求で有効期限ヘッダーを使用してネゴシエートされます。クライアントは、トークンの有効期限が切れる前に、新しいオファー/回答[15] Exchange（たとえば、SIP Re Invite）を使用してトークンを再交渉する必要があります。
Note that this scheme relies on relays as trusted nodes, acting on behalf of the users authenticated to them. There is no security mechanism to prevent relays on the path from inserting forged messages, manipulating the contents of messages, sending messages in a session to a party other than that specified by the sender, or from copying them to a third party. However, the one-to-one binding between session identifiers and sessions helps mitigate any damage that can be caused by rogue relays by limiting the destinations to which forged or modified messages can be sent to the two parties involved in the session, and only for the duration of the session. Additionally, the use of S/MIME encryption can be employed to limit the utility of redirecting messages. Finally, clients can employ S/MIME signatures to guarantee the authenticity of messages they send, making it possible under some circumstances to detect relay manipulation or the forging of messages.
このスキームは、信頼できるノードとしてリレーに依存しており、ユーザーに認証されたユーザーに代わって行動することに注意してください。パス上のリレーが偽造されたメッセージを挿入したり、メッセージの内容を操作したり、セッション内のメッセージを送信者が指定したり、サードパーティにコピーするのを防ぐセキュリティメカニズムはありません。ただし、セッション識別子とセッション間の1対1のバインディングは、鍛造または変更されたメッセージをセッションに関係する2つの関係者に送信できる宛先を制限することにより、ローグリレーによって引き起こされる可能性のある損害を軽減するのに役立ちます。セッションの期間。さらに、S/MIME暗号化の使用を使用して、リダイレクトメッセージのユーティリティを制限できます。最後に、クライアントはS/MIMEシグネチャを使用して、送信するメッセージの信頼性を保証することができ、状況によってはリレー操作やメッセージの鍛造を検出することが可能になります。
Clients are not the only actors in the network who need to trust relays to act in non-malicious ways. If a relay does not have a direct TLS connection with the client on whose behalf it is acting (i.e. There are one or more intervening relays), it is at the mercy of any such intervening relays to accurately transmit the messages sent to and from the client. If a stronger guarantee of the authentic origin of a message is necessary (e.g. The relay is performing logging of messages as part of a legal requirement), then users of that relay can be instructed by their administrators to use detached S/MIME signatures on all messages sent by their client. The relay can enforce such a policy by returning a 415 response to any SEND requests using a top-level MIME type other than "multipart/ signed". Such relays may choose to make policy decisions (such as terminating sessions and/or suspending user authorization) if such signatures fail to match the contents of the message.
クライアントは、非悪質な方法で行動するためにリレーを信頼する必要があるネットワーク内の唯一のアクターではありません。リレーに代わって動作しているクライアントとの直接的なTLS接続がない場合（つまり、1つ以上の介在するリレーがあります）、それはそのような介在するリレーの慈悲であり、クライアント。メッセージの本物の起源をより強力に保証する必要がある場合（たとえば、リレーが法的要件の一部としてメッセージのロギングを実行している場合）、そのリレーのユーザーは、管理者がすべてのデタッチされたS/MIME署名を使用するように指示することができますクライアントから送信されたメッセージ。リレーは、「MultiPart/ Signed」以外のトップレベルMIMEタイプを使用して、送信要求に対する415の応答を返すことにより、このようなポリシーを実施できます。このようなリレーは、メッセージの内容と一致しない場合、ポリシー決定（セッションの終了やユーザー承認の停止など）を選択することを選択する場合があります。
This specification defines a new MSRP method, to be added to the Methods sub-registry under the MSRP Parameters registry: AUTH. See Section 5.1 for details on the AUTH method.
この仕様は、MSRPパラメーターレジストリ：AUTHに基づいてメソッドサブレジストリに追加される新しいMSRPメソッドを定義します。AUTHメソッドの詳細については、セクション5.1を参照してください。
This specification defines several new MSRP header fields, to be added to the header-field sub-registry under the MSRP Parameters registry:
この仕様では、MSRPパラメーターレジストリの下でヘッダーフィールドサブレジストリに追加されるいくつかの新しいMSRPヘッダーフィールドを定義します。
o Expires o Min-Expires o Max-Expires o Use-Path o WWW-Authenticate o Authorization o Authentication-Info
o 期限切れになりますo max-expires o use-path o www-authenticate o承認o認証-info
This specification defines one new MSRP status code, to be added to the Status-Code sub-registry under the MSRP Parameters registry:
この仕様では、MSRPパラメーターレジストリの下でステータスコードサブレジストリに追加される1つの新しいMSRPステータスコードを定義します。
The 401 response indicates that an AUTH request contained no credentials, an expired nonce value, or invalid credentials. The response includes a "WWW-Authenticate" header containing a challenge (among other fields); see Section 9.1 for further details. The default response phrase for this response is "Unauthorized".
401の応答は、認証要求に資格情報、期限切れのNonCE値、または無効な資格情報が含まれていないことを示しています。応答には、チャレンジを含む（他のフィールドの中でも）「www-authenticate」ヘッダーが含まれます。詳細については、セクション9.1を参照してください。この応答のデフォルトの応答句は「不正」です。
The following section shows an example SDP that could occur in a SIP message to set up an MSRP session between Alice and Bob where Bob uses a relay. Alice makes an offer with a path to Alice.
次のセクションでは、SIPメッセージで発生する可能性のあるSDPの例を示しており、ボブがリレーを使用するアリスとボブの間にMSRPセッションをセットアップします。アリスはアリスへの道を提供します。
c=IN IP4 a.example.com
m=message 1234 TCP/MSRP *
a=accept-types: message/cpim text/plain text/html
a=path:msrp://a.example.com:1234/agic456;tcp
In this offer, Alice wishes to receive MSRP messages at a.example.com. She wants to use TCP as the transport for the MSRP session. She can accept message/cpim, text/plain, and text/html message bodies in SEND requests. She does not need a relay to set up the MSRP session.
このオファーでは、アリスはa.example.comでMSRPメッセージを受信したいと考えています。彼女は、MSRPセッションのトランスポートとしてTCPを使用したいと考えています。彼女は、送信リクエストでメッセージ/CPIM、テキスト/プレーン、およびテキスト/HTMLメッセージ本文を受け入れることができます。彼女は、MSRPセッションをセットアップするためにリレーを必要としません。
To this offer, Bob's answer could look like:
この申し出に、ボブの答えは次のようになります。
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types: message/cpim text/plain
a=path:msrps://relay.example.com:9000/hjdhfha;tcp \
msrps://bob.example.com:1234/fuige;tcp
Here Bob wishes to receive the MSRP messages at bob.example.com. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice. He wishes to use a relay called relay.example.com for the MSRP session.
ここで、ボブはbob.example.comでMSRPメッセージを受信したいと考えています。彼は、送信要求でメッセージ/CPIMとテキスト/プレーンメッセージ本文のみを受け入れることができ、アリスが提供するテキスト/HTMLコンテンツを拒否しました。彼は、MSRPセッションにrelay.example.comというリレーを使用したいと考えています。
Many thanks to Avshalom Houri, Hisham Khartabil, Robert Sparks, Miguel Garcia, Hans Persson, and Orit Levin, who provided detailed proofreading and helpful text. Thanks to the following members of the SIMPLE WG for spirited discussions on session mode: Chris Boulton, Ben Campbell, Juhee Garg, Paul Kyzivat, Allison Mankin, Aki Niemi, Pekka Pessi, Jon Peterson, Brian Rosen, Jonathan Rosenberg, and Dean Willis.
Avshalom Houri、Hisham Khartabil、Robert Sparks、Miguel Garcia、Hans Persson、およびOrit Levinに感謝します。セッションモードでの活発な議論のためのシンプルなWGの次のメンバーに感謝します：クリス・ボールトン、ベン・キャンベル、ジュヒー・ガーグ、ポール・キジバット、アリソン・マンキン、アキ・ニエミ、ペッカ・ペッシ、ジョン・ピーターソン、ブライアン・ローゼン、ジョナサン・ローゼンバーグ、ディーン・ウィリス。
[1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[1] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本およびダイジェストアクセス認証」、RFC 2617、1999年6月。
[2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[2] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[3] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[4] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[5] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[6] Chown、P。、「輸送層のセキュリティ（TLS）のための高度な暗号化標準（AES）ciphersuites」、RFC 3268、2002年6月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[8] 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.
[8] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[10] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[11] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[11] Campbell、B.、ed。、Mahy、R.、ed。、およびC. Jennings、ed。、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
[12] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[12] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[13] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[14] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[15] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
This text is not necessary in order to implement MSRP in an interoperable way, but is still useful as an implementation discussion for the community. It is purely an implementation detail.
このテキストは、相互運用可能な方法でMSRPを実装するために必要ではありませんが、コミュニティの実装ディスカッションとして依然として役立ちます。純粋に実装の詳細です。
Note: The idea has been proposed of having a relay return a base URI that the client can use to construct more URIs, but this allows third parties that have had a session with the client to know URIs that the relay will use for forwarding after the session with the third party has ended. Effectively, this reveals the secret URIs to third parties, which compromises the security of the solution, so this approach is not used.
注：このアイデアは、クライアントがより多くのURIを構築するために使用できるベースURIをリレーに戻すことを提案していますが、これにより、クライアントとのセッションがあり、リレーが転送に使用することをURISと知ることができます。サードパーティとのセッションが終了しました。事実上、これは秘密のウリスが第三者に明らかになっており、それがソリューションのセキュリティを損なうため、このアプローチは使用されません。
An alternative to this approach causes the relays to return a URI that is divided into an index portion and a secret portion. The client can encrypt its identifier and its own opaque data with the secret portion, and concatenate this with the index portion to create a plurality of valid URIs. When the relay receives one of these URIs, it could use the index to look up the appropriate secret, decrypt the client portion, and verify that it contains the client identifier. The relay can then forward the request. The client does not need to send an AUTH request for each URI it uses. This is an implementation detail that is out of the scope of this document.
このアプローチに代わるものは、リレーがインデックス部分と秘密部分に分割されたURIを返します。クライアントは、識別子と独自の不透明なデータを秘密部分で暗号化し、これをインデックス部分と連結して、複数の有効なURIを作成することができます。リレーがこれらのURIのいずれかを受信すると、インデックスを使用して適切な秘密を検索し、クライアント部分を復号化し、クライアント識別子が含まれていることを確認できます。リレーはリクエストを転送できます。クライアントは、使用する各URIの認証要求を送信する必要はありません。これは、このドキュメントの範囲外である実装の詳細です。
It is possible to implement forwarding requirements in a farm without the relay saving any state. One possible implementation that a relay might use is described in the rest of this section. When a relay starts up, it could pick a cryptographically random 128-bit password (K) and 128-bit initialization vector (IV). If the relay was actually a farm of servers with the same DNS name, all the machines in the farm would need to share the same K. When an AUTH request is received, the relay forms a string that contains the expiry time of the URI, an indication if the previous hop was mutual TLS authenticated or not, and if it was, the name of the previous hop, and if it was not, the identifier for the connection that received the AUTH request. This string would be padded by appending a byte with the value 0x80 then adding zero or more bytes with the value of 0x00 until the string length is a multiple of 16 bytes long. A new random IV would be selected (it needs to change because it forms the salt) and the padded string would be encrypted using AES-CBC with a key of K. The IV and encrypted data and an SPI (security parameter index) that changes each time K changes would be base 64 encoded and form the resource portion of the request URI. The SPI allows the key to be changed and for the system to know which K should be used. Later when the relay receives this URI, it could decrypt it and check that the current time was before the expiry time and check that the message was coming from or going to the connection or location specified in the URI. Integrity protection is not required because it is extremely unlikely that random data that was decrypted would result in a valid location that was the same as the one the message was routing to or from. When implementing something like this, implementors should be careful not to use a scheme like EBE that would allows portions of encrypted tokens to be cut and pasted into other URIs.
リレーがいかなる状態を救うことなく、農場に転送要件を実装することが可能です。リレーが使用する可能性のある1つの実装は、このセクションの残りの部分で説明されています。リレーが起動すると、暗号化されたランダムな128ビットパスワード（k）および128ビット初期化ベクトル（IV）を選択できます。リレーが実際に同じDNS名を持つサーバーの農場である場合、農場内のすべてのマシンは同じKを共有する必要があります。認証要求を受信すると、リレーはURIの有効期限を含む文字列を形成します。前のホップが相互TLSが認証されているかどうか、それが前のホップの名前であったかどうか、そうでない場合は、認証要求を受信した接続の識別子です。この文字列は、値0x80のバイトを追加して、弦の長さが16バイトの倍数になるまで0x00の値でゼロ以上のバイトを追加することでパッドで埋められます。新しいランダムIVが選択され（塩を形成するために変更する必要があります）、パッド入りの文字列はKのキーを使用してAES-CBCを使用して暗号化されます。kの変更がベース64エンコードされ、リクエストURIのリソース部分を形成するたびに。SPIを使用すると、キーを変更し、システムがどのkを使用するかを知ることができます。後でリレーがこのURIを受信すると、それを復号化し、現在の時刻が有効期限の前であることを確認し、メッセージがURIで指定された接続または場所に送られているか、場所に送られていることを確認できます。整合性保護は、復号化されたランダムデータが、メッセージがルーティングしているものと同じ位置と同じ有効な場所になる可能性が非常に低いため、必要ではありません。このようなものを実装する場合、実装者は、暗号化されたトークンの一部をカットして他のURIに貼り付けることを可能にするEBEのようなスキームを使用しないように注意する必要があります。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems、Inc。170 West Tasman Dr. MS：SJC-21/2 San Jose、CA 95134 USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
Rohan Mahy Plantronics 345 Encincal Street Santa Cruz、CA 95060 USA
EMail: rohan@ekabal.com
Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 USA
Adam Roach Estacado Systems 17210 Campbell Rd。スイート250ダラス、テキサス75252 USA
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。