SIMPLE WG C. Jennings
Internet-Draft Cisco Systems, Inc.
Expires: August 20, 2005 R. Mahy
Airespace
February 19, 2005
Relay Extensions for the Message Sessions Relay Protocol (MSRP)
draft-ietf-simple-msrp-relays-03.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The SIMPLE Working Group uses two separate models for conveying
instant messages. Pager-mode messages stand alone and are not part
of a SIP (Session Initiation Protocol) session, whereas Session-mode
messages are setup as part of a session using the SIP protocol. MSRP
(Message Sessions Relay Protocol) is a protocol for near-real-time,
peer-to-peer exchange of binary content without intermediaries, which
Jennings & Mahy Expires August 20, 2005 [Page 1]
Internet-Draft MSRP Relays February 2005
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.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction and Requirements . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Authorization Overview . . . . . . . . . . . . . . . . . . 9
4. New Protocol Elements . . . . . . . . . . . . . . . . . . . . 10
4.1 The AUTH Method . . . . . . . . . . . . . . . . . . . . . 10
4.2 The Use-Path header . . . . . . . . . . . . . . . . . . . 10
4.3 Authentication headers . . . . . . . . . . . . . . . . . . 11
4.4 Time-related headers . . . . . . . . . . . . . . . . . . . 11
4.5 New Response Codes . . . . . . . . . . . . . . . . . . . . 11
5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Connecting to relays acting on your behalf . . . . . . . . 11
5.2 Sending requests . . . . . . . . . . . . . . . . . . . . . 15
5.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 15
5.4 Managing Connections . . . . . . . . . . . . . . . . . . . 16
6. Relay behavior . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 Handling Incoming Connections . . . . . . . . . . . . . . 16
6.2 Generic request behavior . . . . . . . . . . . . . . . . . 16
6.3 Receiving AUTH requests . . . . . . . . . . . . . . . . . 16
6.4 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4.1 Forwarding SEND requests . . . . . . . . . . . . . . . 17
6.4.2 Forwarding non-SEND requests . . . . . . . . . . . . . 18
6.4.3 Forwarding Responses . . . . . . . . . . . . . . . . . 19
6.4.4 Forwarding unknown requests . . . . . . . . . . . . . 19
6.5 Managing Connections . . . . . . . . . . . . . . . . . . . 19
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Finding MSRP Servers . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1 Using HTTP Authentication . . . . . . . . . . . . . . . . 21
9.2 Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 22
9.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 22
9.4 Security Mechanism . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
11. Example SDP with multiple hops . . . . . . . . . . . . . . . 24
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1 Normative References . . . . . . . . . . . . . . . . . . . . 25
13.2 Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
A. Implementation Consideration . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29
Jennings & Mahy Expires August 20, 2005 [Page 2]
Internet-Draft MSRP Relays February 2005
1. Conventions and Definitions
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 [15].
Below we list several definitions important to MSRP:
MSRP node: a host that implements the MSRP protocols as a Client or a
Relay.
MSRP Client: an MSRP node which is the initial sender or final target
of messages and delivery status.
MSRP Relay: an MSRP node which forwards messages and delivery status
and may provide policy enforcement. Relays can fragment and
reassemble portions of messages.
Message: arbitrary MIME content which 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.
chunk: a portion of a complete message delivered in a SEND request.
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.
2. Introduction and Requirements
The IETF SIMPLE Working Group has identified a number of scenarios
where using a separate protocol for bulk messaging is desirable. In
particular, the SIMPLE WG will use this facility to handle a sequence
of messages as a session of media initiated using SIP [14], just like
any other media type. The SIMPLE Working Group has also developed
MSRP (the Message Sessions Relay Protocol) [18] to convey sessions
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.
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 which
can receive new TCP connections directly do not have to implement any
new functionality to work with these relays.
The Goals of the MSRP Relay extensions are listed below:
o convey arbitrary binary MIME data without modification or transfer
encoding
o continue to support client to client operation (no relay servers
required)
Jennings & Mahy Expires August 20, 2005 [Page 3]
Internet-Draft MSRP Relays February 2005
o operate through an arbitrary number of relays for policy
enforcement
o allow each client to control which relays are traversed on its
behalf
o prevent unsolicited messages (spam), "open relays", and denial of
service amplification
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 allow large messages to be sent over a slow connection without
causing head-of-line blocking problems
o allow transmission of a large message to be interrupted and
resumed in place when network connectivity is lost and later
reestablished
o offer notification of message failure at any intermediary
o provide notification of message storage (desirable)
o allow relays to delete state after a short amount of time
3. Protocol Overview
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 which can open TCP connections to
each other without intervening policy restrictions, can communicate
directly with each other. Clients who are behind a firewall or who
need to use an intermediary 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 half of the communication.
Clients which 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 authenticates using an
AUTH request contain appropriate authentication credentials. In a
successful AUTH response, the relay provides an msrps: URI associated
with the path back to the client that the client can give to other
clients for end-to-end message delivery.
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.
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
Jennings & Mahy Expires August 20, 2005 [Page 4]
Internet-Draft MSRP Relays February 2005
SEND message 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 sent end-to-end.
With the introduction of relays, the subtle semantics of the To-Path
and From-Path header becomes 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 . This differs 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.)
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 this: (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
are included in the actual request or response.)
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 must send a 200 response to the
request. The 200 response acknowledges the receipt of the request so
that the pervious 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 not set to "no", then it sends a
REPORT to tell the sender about the error. In the case that
Failure-Report is set to "yes", after the relay is done sending the
request to the next hop, it starts running a timer and if the timer
Jennings & Mahy Expires August 20, 2005 [Page 5]
Internet-Draft MSRP Relays February 2005
expires before a 200 is received from the next hop, the relay assumes
that an error have 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.
The following example show a typical MSRP session. The AUTH request
are explained in a later section but left in the example for call
flow completeness.
Alice a.example.org b.example.net Bob
| | | |
|::::::::::::::::::::>| connection opened |<::::::::::::::::::::|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 401 Auth---------| |--- 401 Auth-------->|
|--- 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 are included in the actual request or response.)
MSRP 6aef SEND
To-Path: msrps://example.org:9000/kjfjan;tcp \
msrps://example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://alice.example.com: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
Jennings & Mahy Expires August 20, 2005 [Page 6]
Internet-Draft MSRP Relays February 2005
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps://alice.example.com:7965/bar;tcp
From-Path: msrps://example.org:9000/kjfjan;tcp
-------6aef$
MSRP juh76 SEND
To-Path: msrps://example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://example.org:9000/kjfjan;tcp \
msrps://alice.example.com: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://example.org:9000/kjfjan;tcp
From-Path: msrps://example.net:9000/aeiug;tcp
-------juh76$
MSRP xght6 SEND
To-Path: msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://example.net:9000/aeiug;tcp \
msrps://example.org:9000/kjfjan;tcp \
msrps://alice.example.com: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://example.net:9000/aeiug;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Jennings & Mahy Expires August 20, 2005 [Page 7]
Internet-Draft MSRP Relays February 2005
MSRP yh67 REPORT
To-Path: msrps://example.net:9000/aeiug;tcp \
msrps://example.org:9000/kjfjan;tcp \
msrps://alice.example.com: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://example.org:9000/kjfjan;tcp \
msrps://alice.example.com:7965/bar;tcp
From-Path: msrps://example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;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://alice.example.com:7965/bar;tcp
From-Path: msrps://example.org:9000/kjfjan;tcp \
msrps://example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: 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 4GB 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.
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 set the Success-Report header to yes,
Jennings & Mahy Expires August 20, 2005 [Page 8]
Internet-Draft MSRP Relays February 2005
once a chunk or complete message arrives at the destination client,
the destination sends 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 is acknowledged
along every hop, REPORT responses are never acknowledged.
The following example shows a message being re-chunked through two
relays:
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 0-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 0-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 0-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 0-3 ------|
| |<-- REPORT 0-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 0-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 state for a short period of time for
each chunk. Delivery over each hop should take no more than 32
seconds after the last byte of data is sent. Clients applications
define their own implementation-dependent timers for end-to-end
message delivery.
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 another relay) to deliver requests such as SEND or
REPORT. Responses can only be sent over existing connections.
3.1 Authorization Overview
A key element of this protocol is that it must not 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.
Jennings & Mahy Expires August 20, 2005 [Page 9]
Internet-Draft MSRP Relays February 2005
Because of this, clients use an AUTH message to authenticate to a
relay and get a URI that can be used for forwarding messages.
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 Basic Authentication [1] to the
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.
A typical challenge response flow is shown below:
Alice a.example.org
| |
|::::::::::::::::::::>|
|--- AUTH ----------->|
|<-- 401 Auth---------|
|--- AUTH ----------->|
|<-- 200 OK-----------|
| |
The URI that the client should use is returned in the the Use-Path
header of the 200.
TODO - why you authenticate once per session, why URI should be
different, risk of people learning URIs.
4. New Protocol Elements
4.1 The AUTH Method
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.
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.
4.2 The Use-Path header
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.
Jennings & Mahy Expires August 20, 2005 [Page 10]
Internet-Draft MSRP Relays February 2005
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 path attributes from information in
the Use-Path header is discussed in Section 5.1.
4.3 Authentication headers
The Authorization header contains authentication credentials for HTTP
Basic authentication in an AUTH request. The usage of Basic
authentication is described in detail in Section [x.y] of RFC 2617
[1]. This header MUST NOT appear in any MSRP message other than an
AUTH request.
The WWW-Authenticate header contains the realm and a challenge for
credentials, carried in a 401 "Unauthorized" Response.
4.4 Time-related headers
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.
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.
4.5 New Response Codes
This specification defines two new MSRP response codes. The 401
response indicates that an AUTH request was sent which needs to be
authenticated in the realm provided in the WWW-Authenticate header.
The default response phrase is "Unauthorized". The 423 response
indicates that the duration of an Expire header contained in the
corresponding request was either too long or too short. The response
includes a Max-Expires or Min-Expires header, respectively, with a
value which is acceptable to the relay. The default response phrase
for this response is "Interval Out-of-Bounds".
5. Client behavior
5.1 Connecting to relays acting on your behalf
Clients which want to use the services of a relay or list of relays,
Jennings & Mahy Expires August 20, 2005 [Page 11]
Internet-Draft MSRP Relays February 2005
need to send an AUTH request to each relay which 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 with
send an AUTH to intra-org and get back a path that could be used for
forwarding through intra-org. The client would then send a second
AUTH that was destined to extra-org but sent through intra-org. The
intra-org relay would forward this to extra-org and the extra-org
would return a path that could be used to forward messages from this
client to intra-org to extra-org and then on to another destination.
All the relays authenticate the client. The client authenticates the
first relay and each relay authenticates the next relay.
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 each 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. Each relay MUST authenticate the client using Basic
authentication.
The relay will return a URI, or list of URIs, in the Use-Path header
of the 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 setup 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.
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".
Jennings & Mahy Expires August 20, 2005 [Page 12]
Internet-Draft MSRP Relays February 2005
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
When sending an AUTH request, the client MAY add an Expires header to
request a MSRP URI that is valid for no longer that the provided
interval. If an AUTH request returns a 401 Unauthorized request, the
client SHOULD fetch the realm from the WWW-Authenticate header in the
response and retry the AUTH request, including an Authorization
header with the correct credentials for the realm. Unlike in HTTP
and SIP, authentication headers in MSRP are only permitted for AUTH
requests.
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 messages by setting the To-Path to
msrps://R1;tcp msrps://R2;tcp. R1 will forward this (just like a
REPORT request) onward to R2.
(Alice opens a TLS connection to intra.example.com)
MSRP 676sd AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------676sd$
MSRP 676sd 401 Authenticate
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
WWW-Authenticate: Basic realm="intra.example.com"
-------676sd$
MSRP 49fh AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Jennings & Mahy Expires August 20, 2005 [Page 13]
Internet-Draft MSRP Relays February 2005
-------49fh$
MSRP 49fh 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
-------49fh$
(Alice now sends an AUTH request to her "external" relay through her
"internal" relay, using the URI she just obtained)
MSRP quiyd2 AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------quiyd2$
MSRP quiyd2 AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
-------quiyd2$
MSRP quiyd2 401 Authenticate
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: Basic realm="extra.example.com"
-------quiyd2$
MSRP quiyd2 401 Authenticate
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp \
msrps://extra.example.com;tcp
WWW-Authenticate: Basic realm="extra.example.com"
-------quiyd2$
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
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-------mnbvw$
Jennings & Mahy Expires August 20, 2005 [Page 14]
Internet-Draft MSRP Relays February 2005
MSRP mnbvw 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: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-------mnbvw$
MSRP mnbvw 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
-------mnbvw$
MSRP mnbvw 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp \
msrps://extra.example.com;tcp
Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
-------mnbvw$
5.2 Sending requests
The procedure for forming SEND and REPORT requests is identical for
clients whether relays are involved or not. The specific procedures
are described in section 7 of the core MSRP protocol.
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 an existing suitable 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, however in most
simple implementations a connection will be suitable if it exists and
is in an active state.
5.3 Receiving Requests
The procedure for receiving requests is identical for clients whether
relays are involved or not.
Jennings & Mahy Expires August 20, 2005 [Page 15]
Internet-Draft MSRP Relays February 2005
5.4 Managing Connections
Clients should open connection whenever they wish to deliver a
request and no suitable connection exists. For client to client
connections, a client should close a connection when there are no
longer any sessions associated with the connection. For connections
to relays, the client should leave a connection up until no sessions
are using the connection for a locally defined period of time, which
defaults to 5 minutes for foreign relays and one hour for the
client's relays.
6. Relay behavior
6.1 Handling Incoming Connections
When a relay receives an incoming connection on a port configured for
TLS, it includes a client CertificateRequest in the same record that
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. 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 where sent successfully, the server
SHOULD close the connection.
6.2 Generic request behavior
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.
6.3 Receiving AUTH requests
When a relay receives an AUTH request the first thing it does is to
authenticate the previous hop and the client at the far end. If
there are no other relays between this relay and client, then these
are the same thing. To authenticate these two elements, the relay
must authenticate the client that sent the AUTH request with HTTP
Basic authentication and it must also authenticate the previous hop
that sent the message to it. When previous hop is a relay, this is
done with the TLS using mutual authentication. When the previous
hop is a client, the previous hop is considered to be the same as the
Jennings & Mahy Expires August 20, 2005 [Page 16]
Internet-Draft MSRP Relays February 2005
identity of the client and no special authentication is required of
the previous hop. The relay only checks that this client is allowed
to use the relay. If the client is not authorized, the relay returns
an error. If the client has requested a particular expiration time
in an Expires header, the relay must check that the time is
acceptable to it and if not return an error containing a Min-Expires
or Max-Expires header as appropriate.
Next the relay will generate an MSRP URI which allows messages to be
forwarded to or from this previous hop. If the previous hop was
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 was not authenticated by mutual TLS, then the URI
MUST only be valid to route across the same connection over which
AUTH was received. If this connection is closed and then reopened,
the URI MUST be invalidated. If the AUTH request contains an Expires
header, the relay MUST ensure that the URI is invalidated after the
expiry time. 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 the AUTH URI was bad.
A successful AUTH response returns a Use-Path header which contains
an MSRP URI that the client can use. It also returns an Expires
header that indicates how long the URI will be valid for.
If the relay receives several unsuccessful AUTH requests from a
directly connected host, the relay SHOULD terminate the corresponding
connection.
6.4 Forwarding
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. It
MUST then check that one of the following conditions is true: 1) the
place it is forwarding it to corresponds to the previous hop used in
the AUTH that created the URI, or 2) the message being forwarded is
from the previous hop used in the AUTH to create the URI.
6.4.1 Forwarding SEND requests
If an incoming SEND request Failure-Report header with a value of
"yes", a 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 to the previous hop, which could be a MSRP
relay or the original sender of the SEND request.
Jennings & Mahy Expires August 20, 2005 [Page 17]
Internet-Draft MSRP Relays February 2005
If there is a problem further processing the SEND request, or in the
response that the relay receives in sending the SEND request to the
next hop, and the Failure-Report header is "yes" or "partial", then
the relay MUST respond with an appropriate error response in a REPORT
back to the previous hop.
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 of the message has been sent to the next
hop. If after 32 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.
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 Hops header.
The MSRP relay MUST NOT combine message fragments from SEND requests
with different values in the Message-ID header.
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 which is administered, or based on the network speed to the
next hop, or any other mechanism.
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.
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.
6.4.2 Forwarding non-SEND requests
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 header, 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.
Jennings & Mahy Expires August 20, 2005 [Page 18]
Internet-Draft MSRP Relays February 2005
6.4.3 Forwarding Responses
Relays receiving a response, first check the transaction of the
response. If the response is a 200 response, and the relay is
unaware of this transaction, the response MUST be dropped. Likewise
if the message can not be parsed, the relay MUST drop the response.
The relay MUST verify that the first URI in the To-Path corresponds
to it and if not, the response SHOULD be dropped.
If the response matches an existing transaction, the transaction
state is deleted and any timers running on it are removed. If the
response is a non 200 response response, and the original request had
a Failure-Report header value that was not "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.
If there are additional URIs in the To-Path header, the relay can
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 which corresponds to the next URI in the To-Path
header. If this connection has closed, then the response is silently
discarded.
6.4.4 Forwarding unknown requests
Requests with an unknown method are forwarded as if they were REPORT
requests. An device MAY be configured to block unknown methods for
security reasons.
6.5 Managing Connections
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 could be closed. If the relay runs out of resources and
must close connections, it should start closing connections on a
least recently used basis.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [17].
header = Message-ID
/ Success-Report
/ Failure-Report
Jennings & Mahy Expires August 20, 2005 [Page 19]
Internet-Draft MSRP Relays February 2005
/ Byte-Range
/ Status
/ Authorization
/ WWW-Authenticate
/ Expires
/ Min-Expires
/ Max-Expires
/ Use-Path
/ ext-header
AUTHm = %x41.55.54.48 ; AUTH in caps
Method = SENDm / REPORTm / AUTHm
/ ext-method
Authorization = "Authorization" HCOLON credentials
credentials = ("Basic" SP 1*base64char)
/ other-response
base64char = alphanum / "+" / "/" / "="
other-response = auth-scheme SP auth-param
*(COMMA auth-param)
auth-scheme = token
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
challenge = ("Basic" SP realm)
/ other-challenge
other-challenge = auth-scheme SP auth-param
*(COMMA auth-param)
realm = "realm" EQUAL realm-value
realm-value = quoted-string
Expires = "Expires" ":" SP 1*DIGIT
Min-Expires = "Min-Expires" ":" SP 1*DIGIT
Max-Expires = "Max-Expires" ":" SP 1*DIGIT
Use-Path = "Use-Path" ":" SP URI *(SP URI)
8. Finding MSRP Servers
When resolving an MSRP URI which 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 following rules allow MSRP clients to discover MSRP
relays more easily in AUTH requests.
Jennings & Mahy Expires August 20, 2005 [Page 20]
Internet-Draft MSRP Relays February 2005
If the hostport of an msrps: URI is an IPv4 address or an IPv6
reference and no port number is provided, use the default port number
assigned by IANA. If the hostport is a domain name and an explicit
port number is provided, attempt to lookup a valid address record (A
or AAAA) for the domain name. Connect using TLS over the default
transport (TCP) with the default port number.
If a domain name is provided, but no port number, perform a DNS SRV
[7] lookup for the domain and select the entry with the highest
weight. If no SRV records are found, try an address lookup (A or
AAAA) using the default port number procedures described in the
previous paragraph. Note that AUTH requests MUST only be sent over a
TLS-protected channel. An SRV lookup in the example.com domain might
return:
;; 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.
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.
9. Security Considerations
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.
9.1 Using HTTP Authentication
AUTH requests MUST be authenticated. The authentication mechanism
described in this specification uses HTTP Basic authentication. HTTP
Basic authentication is done as described in [RFC 2617], Section 2.
The realm string provided by a relay SHOULD be the same as the host
portion of URIs used to contact that MSRP relay.
This specification uses Basic authentication, which sends an
effectively plain text password over the communications channel. In
this specification all authentication occurs over a TLS-protected
channel, which provides confidentiality, message integrity, and
server authentication. When used over TLS-protected channels, the
only weakness of Basic authentication in MSRP is that "inner" relays
can view the credentials used to authenticate with "outer" relays.
When multiple relays are under the administration of a single domain,
Jennings & Mahy Expires August 20, 2005 [Page 21]
Internet-Draft MSRP Relays February 2005
this is unlikely to be a major problem. If a client tried to use an
"inner" MSRP relay in a hotel (for example) to reach an "outer"
company MSRP relay, the hotel could view credentials used by the
client with the company relay. However, the client should not be
configured to send requests through the hotel relay. (If the hotel
offers "Internet access" but does not allow an outbound TLS
connection to the company relay, the guest may want to stay
elsewhere.) The company relay should also be configured to reject
AUTH requests sent from the hotel relay, since there is no
pre-existing trust relationship with the hotel relay. This
discourages clients from using the services of untrusted relays.
9.2 Using TLS
TLS is used to authenticate relays to senders and to provide
integrity and confidentiality for the headers being transported.
MSRP client and relays MUST support TLS. Clients and relays MUST
support the TLS ClientExtendedHello extended hello information for
server name indication as described in RFC 3546 [8]. A TLS
cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [9] MUST be supported
(other cipher-suites MAY also be supported). Relays must act as TLS
servers and present a certificate with their 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.
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 they are used when no relays are
involved.
9.3 Threat Model
This section discuses the threat model and the broad mechanism that
must come into place to secure the protocol. The next section
describes the details of how the protocol mechanism meet 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 operation for
them. This combined set of relays is referred to as the route set.
There often exists a channel outside of MSRP, 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
Jennings & Mahy Expires August 20, 2005 [Page 22]
Internet-Draft MSRP Relays February 2005
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 firewall traversal of the ISPs firewall would likely not be
trusted with the contents of the session but would be trusted to
correctly forward messages.
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 the client is the authorized client for them
to forward information to. Clients need the option of ensuring
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 must always be
integrity protected and encrypted regardless of if the client request
it or not. There is no way for the clients to tell the relays what
strength of crypto to use between relays other than the clients to
choose to use relays that are operated by people requiring an
adequate level of security.
The system also needs to stop the messages from being directed to
relays that are not supposed to see them. To keep the relays from
being used in DDoS attacks, the relays must not forward messages
unless they have a trust relationship with either the client sending
or receiving the message and that they only forward that message if
it is coming from or going to the client they have the trust
relationship with. 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 the client that is the destination.
Some terminology used in this discussion is 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.
9.4 Security Mechanism
Confidentiality and Privacy from elements not in the route set is
provided by using TLS on all the transports. If a client decided to
not use TLS that is it's choice but relays must use TLS. Clients
must implement TLS.
The relays authenticate to the clients using TLS (but don't have to
do mutual TLS). The clients authenticate to the relays using HTTP
Basic authentication inside a TLS-protected channel. Relays
authenticate to each other using TLS mutual authentication.
Jennings & Mahy Expires August 20, 2005 [Page 23]
Internet-Draft MSRP Relays February 2005
The clients can protect their actual message contents so that the
relays can not see the contents by using S/MIME encryption. End to
end signing is also possible with S/MIME.
The complex part is making sure that relays do not 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 must only ever be seen by
elements in the route set or other elements that at least one of the
parties trusts. If some 3rd party discovers the token that RRelay2
uses to forward messages to RClient, then that 3rd party can send as
many messages as they want to RRelay2 and it will forward them to
RClient. The 3rd party can not 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.
When SClient goes to get a token from SRelay2, this request is
relayed through SRelay1. SRelay 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.
The tokens are carried in the resource portion of the MSRP URLs. 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 SIP re-invite for the session before the tokens
expire.
10. IANA Considerations
This document introduces no requirements for IANA.
11. Example SDP with multiple hops
The following section shows an example SDP that could occur in a SIP
message to set up a MSRP session between Alice and bob where Bob uses
a relay. Alice makes an offer with a path to Alice.
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
Jennings & Mahy Expires August 20, 2005 [Page 24]
Internet-Draft MSRP Relays February 2005
accept message/cpim, text/plain and text/html message bodies in SEND
requests. She does not need a relay to setup the MSRP session.
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@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.
12. Acknowledgments
Many thanks to Avshalom Houri provided detailed proof reading and
helpful text. Thanks to the following members of the SIMPLE WG for
spirited discussions on session mode: Ben Campbell, Jonathan
Rosenberg, Robert Sparks, Paul Kyzivat, Allison Mankin, Jon Peterson,
Brian Rosen, Dean Willis, Adam Roach, Aki Niemi, Hisham Khartabil,
Juhee Garg, Pekka Pessi, Avshalom Houri, and Chris Boulton.
13. References
13.1 Normative References
[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.
[2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[5] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
Jennings & Mahy Expires August 20, 2005 [Page 25]
Internet-Draft MSRP Relays February 2005
[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003.
[9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[10] Troost, R., Dorner, S. and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[11] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[14] 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.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[16] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[17] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[18] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-09 (work in progress),
October 2004.
Jennings & Mahy Expires August 20, 2005 [Page 26]
Internet-Draft MSRP Relays February 2005
13.2 Informative References
[19] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.
[20] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[21] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[22] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[23] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Authors' Addresses
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
Airespace
110 Nortech Parkway
San Jose, CA 95134
USA
EMail: rohan@ekabal.com
Appendix A. Implementation Consideration
This section includes text which will be deleted in the next version
of the document, and moved to another document. 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.
Note: The idea has been proposed of having a relay return a base URL
that the client can use to construct more URLs but this allows 3rd
Jennings & Mahy Expires August 20, 2005 [Page 27]
Internet-Draft MSRP Relays February 2005
parties that have had a session with the client to know URLs that the
relay will use for forwarding after the session with the 3rd party
has ended. Effectively this reveals the secret URIs to 3rd parties
which compromises the security of the solution so this approach is
not used.
An alternative to this approach causes the relays to return a URI
which 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 lookup 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 which is out of scope of this document.
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 crypto 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 was 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, if it was not, the
identifier for the connection which 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 vector 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
messages 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 messages was
routing to or from. When implementing something like this,
implementers should be careful not to use a scheme like EBE that
would allows portion of encrypted tokens to be cut and paste into
other URIs.
Jennings & Mahy Expires August 20, 2005 [Page 28]
Internet-Draft MSRP Relays February 2005
Intellectual Property Statement
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.
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.
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings & Mahy Expires August 20, 2005 [Page 29]
