Relay Extensions for the Message Sessions Relay Protocol (MSRP)
updated by
Extracted elements (26)
SEND requests use hop-by-hop acknowledgment by default (each relay acknowledges receipt before forwarding), while all other requests are acknowledged end-to-end. This allows relays to run failure timers on a per-hop basis and send REPORT notifications to the original sender.
The approach of having a relay return a base URI from which the client derives multiple URIs was explicitly rejected because it would reveal secret URI tokens to third parties who participated in prior sessions, compromising the security of future sessions.
Clients that can open TCP connections to each other without policy restrictions can communicate directly using the base MSRP protocol. No new client functionality is required to work with relays in the receiving direction; only senders need to implement relay extensions.
When a relay forwards non-SEND requests (including unknown methods), it forwards them as if they were REPORT requests. An MSRP node MAY be configured to block unknown methods for security reasons.
A client MUST authenticate itself to each of its relays using HTTP Digest authentication. The client MUST be able to form a connection to the first relay and send an AUTH command to get a URI for use in the To-Path header.
A relay MUST NOT combine message fragments from SEND requests that have different values in the Message-ID header. Relays MAY re-fragment or reassemble chunks from the same message and forward them in different SEND requests, but MUST resend resulting chunks in order.
AUTH requests MUST only be sent over a TLS-protected channel. When no explicit port is provided in the URI, a DNS SRV lookup for the '_msrps' service and '_tcp' transport is performed; if no SRV records are found, a default port of 2855 is used.
Before forwarding any request, a relay MUST verify that the first URI in the To-Path header corresponds to a URI it issued in a Use-Path response, and that the message is coming from or going to the authorized client that obtained that URI.
Clients MUST NOT attempt to use Basic authentication and relays MUST NOT request or accept it. Relays MUST NOT indicate qop=auth-int or the MD5-sess algorithm in challenges. Clients and relays MUST include a qop parameter in all WWW-Authenticate and Authorization headers.
Each URI returned in the Use-Path header SHOULD be used for only one unique session. The client MUST NOT reuse the same URI for multiple sessions and must protect these URIs from eavesdropping.
If an incoming SEND request has Failure-Report set to 'yes', the relay MUST immediately respond with a final response to the previous hop. If after 30 seconds the next hop has not responded, the relay MUST construct and send a REPORT with status code 408.
MSRP clients and relays MUST implement TLS. The cipher suite TLS_RSA_WITH_AES_128_CBC_SHA MUST be supported. Clients MUST send TLS ClientExtendedHello with server name indication (RFC 4366).
Relay-to-relay connections MUST use TLS with mutual authentication. Client-to-relay communications MUST use TLS for AUTH requests and responses. A relay MUST present a certificate with its identity in the SubjectAltName as a dnsName.
Relays MUST include rspauth, cnonce, nc, and qop parameters in an Authentication-Info header for all 200 OK responses to an AUTH request. The request-URI used in calculating H(A2) is the rightmost URI in the To-Path header.
The MSRP URI returned by a relay in a Use-Path MUST contain at least 64 bits of cryptographically random material so it is not guessable by attackers. The URI MUST be invalidated when the client's connection is closed and reopened, and MUST be invalidated after the Expires time.
The SubjectAltName in a relay's TLS certificate MUST match the hostname portion of the MSRP URI. The certificate MUST be valid per RFC 3280, including having a valid date and being signed by an acceptable CA.
When a relay receives an AUTH request without an Authorization header, it MUST respond with a 401 Unauthorized containing a WWW-Authenticate header. Upon receiving a 401, the client SHOULD retry with correct credentials in an Authorization header.
The AUTH method is a new MSRP request used by clients to create a handle for receiving incoming requests. In response to a successful AUTH, the relay returns a Use-Path header containing URIs the client can give its peers for routing messages back to it.
The Expires header in an AUTH request indicates how long the client wants the returned URI to remain valid (in whole seconds). Min-Expires and Max-Expires headers are sent by the relay in 423 responses to indicate acceptable bounds.
The Use-Path header is a list of MSRP URIs returned by a relay in a successful AUTH response. URIs in Use-Path MUST include a fully qualified domain name (not a numeric IP address) and an explicit port number.
When a relay forwards a request, it removes its own URI from the beginning of the To-Path header and inserts it as the first URI in the From-Path header. This maintains the full reverse path for responses and REPORT messages.
This document registers in the MSRP Parameters registry: one new method (AUTH), nine new header fields (Expires, Min-Expires, Max-Expires, Use-Path, WWW-Authenticate, Authorization, Authentication-Info), and one new response code (401 Unauthorized).
If a relay receives several unsuccessful AUTH requests from a directly-connected client, it SHOULD terminate that connection. This measure applies only to client connections and SHOULD NOT be used as a reason to terminate relay-to-relay connections.
Relays never forward messages unless they have a trust relationship with either the sending or receiving client, and only forward a message coming from or going to the client that holds the matching URI token. This prevents open-relay abuse and DoS amplification.
There is no mechanism to prevent relays on the path from inserting forged messages, modifying message contents, or copying them to third parties. Clients can use S/MIME encryption for content confidentiality and S/MIME signatures to detect relay manipulation.
Use-Path URI tokens must be treated as secrets shared only between the two MSRP clients in a session. If a third party discovers a token it can inject messages to the receiving relay, though the relay will only forward them to the authorized destination client.