[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4976

SIMPLE WG                                                    C. Jennings
Internet-Draft                                       Cisco Systems, Inc.
Expires: December 23, 2005                                       R. Mahy
                                                           June 21, 2005

    Relay Extensions for the Message Sessions Relay Protocol (MSRP)

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   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
   is designed to be signaled using a separate rendezvous protocol such

Jennings & Mahy         Expires December 23, 2005               [Page 1]

Internet-Draft                 MSRP Relays                     June 2005

   as SIP.  This document introduces the notion of message relay
   intermediaries to MSRP and describes the extensions necessary to use

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   The HTTP Authentication "Authorization" header . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 14
     5.3   Receiving Requests . . . . . . . . . . . . . . . . . . . . 15
     5.4   Managing Connections . . . . . . . . . . . . . . . . . . . 15
   6.  Relay behavior . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1   Handling Incoming Connections  . . . . . . . . . . . . . . 15
     6.2   Generic request behavior . . . . . . . . . . . . . . . . . 15
     6.3   Receiving AUTH requests  . . . . . . . . . . . . . . . . . 16
     6.4   Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 16
       6.4.1   Forwarding SEND requests . . . . . . . . . . . . . . . 17
       6.4.2   Forwarding non-SEND requests . . . . . . . . . . . . . 18
       6.4.3   Handling Responses . . . . . . . . . . . . . . . . . . 18
     6.5   Managing Connections . . . . . . . . . . . . . . . . . . . 18
   7.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  Finding MSRP Relays  . . . . . . . . . . . . . . . . . . . . . 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
     9.1   Using HTTP Authentication  . . . . . . . . . . . . . . . . 20
     9.2   Using TLS  . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.3   Threat Model . . . . . . . . . . . . . . . . . . . . . . . 21
     9.4   Security Mechanism . . . . . . . . . . . . . . . . . . . . 22
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 23
   11.   Example SDP with multiple hops . . . . . . . . . . . . . . . 23
   12.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 24
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24
     13.1  Normative References . . . . . . . . . . . . . . . . . . . 24
     13.2  Informative References . . . . . . . . . . . . . . . . . . 26
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
   A.  Implementation Consideration . . . . . . . . . . . . . . . . . 26
       Intellectual Property and Copyright Statements . . . . . . . . 28

Jennings & Mahy         Expires December 23, 2005               [Page 2]

Internet-Draft                 MSRP Relays                     June 2005

1.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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
   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
   o  continue to support client to client operation (no relay servers

Jennings & Mahy         Expires December 23, 2005               [Page 3]

Internet-Draft                 MSRP Relays                     June 2005

   o  operate through an arbitrary number of relays for policy
   o  allow each client to control which relays are traversed on its
   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
   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 side 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 containing 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 December 23, 2005               [Page 4]

Internet-Draft                 MSRP Relays                     June 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 \
   From-Path: msrps://A.example.com/aaa;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 \

   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
   the 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

Jennings & Mahy         Expires December 23, 2005               [Page 5]

Internet-Draft                 MSRP Relays                     June 2005

   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 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.

   The following example show a typical MSRP session.  The AUTH requests
   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 ------------|
     |<-- 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://a.example.org:9000/kjfjan;tcp \
     msrps://b.example.net:9000/aeiug;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

Jennings & Mahy         Expires December 23, 2005               [Page 6]

Internet-Draft                 MSRP Relays                     June 2005


    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

    MSRP juh76 SEND
    To-Path: msrps://b.example.net:9000/aeiug;tcp \
    From-Path: msrps://a.example.org:9000/kjfjan;tcp \
    Success-Report: yes
    Message-ID: 87652
    Byte-Range: 1-*/*
    Content-Type: text/plain

    Hi Bob, I'm about to send you file.mpeg

    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

    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 \
    Success-Report: yes
    Message-ID: 87652
    Byte-Range: 1-*/*
    Content-Type: text/plain

    Hi Bob, I'm about to send you file.mpeg

    MSRP xght6 200 OK
    To-Path: msrps://b.example.net:9000/aeiug;tcp
    From-Path: msrps://bob.example.net:8145/foo;tcp

Jennings & Mahy         Expires December 23, 2005               [Page 7]

Internet-Draft                 MSRP Relays                     June 2005

    Message-ID: 87652

    MSRP yh67 REPORT
    To-Path: msrps://b.example.net:9000/aeiug;tcp \
     msrps://a.example.org:9000/kjfjan;tcp \
    From-Path: msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652
    Byte-Range: 1-39/39
    Status: 000 200 OK

    MSRP yh67 REPORT
    To-Path: msrps://a.example.org:9000/kjfjan;tcp \
    From-Path: msrps://b.example.net:9000/aeiug;tcp \
     From-Path: msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652
    Byte-Range: 1-39/39
    Status: 000 200 OK

    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 \
    From-Path: msrps://bob.example.net:8145/foo;tcp
    Message-ID: 87652
    Byte-Range: 1-39/39
    Status: 000 200 OK

   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

Jennings & Mahy         Expires December 23, 2005               [Page 8]

Internet-Draft                 MSRP Relays                     June 2005

   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,
   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 can be
   acknowledged along every hop, REPORT requests are never acknowledged.

   The following example shows a message being re-chunked through two

   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 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

Jennings & Mahy         Expires December 23, 2005               [Page 9]

Internet-Draft                 MSRP Relays                     June 2005

   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.

   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
   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 ----------->|
     |<-- 200 OK-----------|
     |                     |

   The URI that the client should use is returned in the the Use-Path
   header of the 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.

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

Jennings & Mahy         Expires December 23, 2005              [Page 10]

Internet-Draft                 MSRP Relays                     June 2005

   requests, and to advertise this list of URIs, for example in a
   session description.

   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  The HTTP Authentication "Authorization" header

   The "Authorization" header contains authentication credentials for
   HTTP Basic Authentication (from RFC 2617 [1]) in an AUTH request.
   The usage of HTTP Basic authentication in MSRP is described in detail
   in Section 5.1.  This header MUST NOT appear in any MSRP message
   other than an AUTH request.

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 a new MSRP response code.  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,
   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

Jennings & Mahy         Expires December 23, 2005              [Page 11]

Internet-Draft                 MSRP Relays                     June 2005

   the AUTH requests to the outer relay.  For example, the client will
   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 extra-org would
   return a path that could be used to forward messages from another
   destination to extra-org to intra-org and then on to this client.
   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 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 Basic authentication [1].

   The relay will return 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 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

     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

Jennings & Mahy         Expires December 23, 2005              [Page 12]

Internet-Draft                 MSRP Relays                     June 2005

   To-Path header generated by A:    B C D E F

   When sending an AUTH request, the client MUST include a single
   Authorization header which contains the credentials (username and
   password) for the relay which is the target of the AUTH request.  The
   Authorization header is formed as described in Section 2 of RFC 2617
   [1].  The credentials are protected from eavesdropping and
   modification on the wire because they are always sent inside a TLS-
   protected channel.  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 message by setting the To-Path to
   msrps://R1;tcp msrps://R2;tcp.  R1 will forward this request onward
   to 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 (an 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.

   (Alice opens a TLS connection to intra.example.com.  Alice
   authenticates to the inner relay using the username "alice" and the
   password "myinnerpassword".)

    MSRP 49fh AUTH
    To-Path: msrps://alice@intra.example.com;tcp
    From-Path: msrps://alice.example.com:9892/98cjs;tcp
    Authorization: Basic YWxpY2U6bXlpbm5lcnBhc3N3b3JkCg==

    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
    Expires: 1800

   (Alice now sends an AUTH request to her "external" relay through her
   "internal" relay, using the URI she just obtained.  Alice
   authenticates to the outer relay using the username

Jennings & Mahy         Expires December 23, 2005              [Page 13]

Internet-Draft                 MSRP Relays                     June 2005

   "alice@div1.example.com" and the password "aBetter0uts1dePasswd!". )

    MSRP mnbvw AUTH
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
    From-Path: msrps://alice.example.com:9892/98cjs;tcp
    Authorization: Basic \

    MSRP mnbvw AUTH
    To-Path: msrps://extra.example.com;tcp
    From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
    Authorization: Basic \

    MSRP mnbvw 200 OK
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
    From-Path: msrps://extra.example.com;tcp
    Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
    Expires: 900

    MSRP mnbvw 200 OK
    To-Path: msrps://intra.example.com:9000/jui787s2f;tcp
    From-Path: msrps://alice.example.com:9892/98cjs;tcp \
    Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
    Expires: 900

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

Jennings & Mahy         Expires December 23, 2005              [Page 14]

Internet-Draft                 MSRP Relays                     June 2005

   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.

5.4  Managing Connections

   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 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

Jennings & Mahy         Expires December 23, 2005              [Page 15]

Internet-Draft                 MSRP Relays                     June 2005

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.  When the previous hop is a relay, this is done
   with TLS using mutual authentication.  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 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 the
   AUTH request 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 (expressed as a
   whole number of seconds).

   If the relay receives several unsuccessful AUTH requests from a
   directly connected host, the relay SHOULD terminate the corresponding

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.

Jennings & Mahy         Expires December 23, 2005              [Page 16]

Internet-Draft                 MSRP Relays                     June 2005

6.4.1  Forwarding SEND requests

   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

   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 original source of the message.

   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 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, and send the
   REPORT to the original sender 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.

   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.  In this case the relay SHOULD discard

Jennings & Mahy         Expires December 23, 2005              [Page 17]

Internet-Draft                 MSRP Relays                     June 2005

   the message and if the Failure-Report header is set to "yes", the
   relay SHOULD generate a failure report.

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.

   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.

6.4.3  Handling Responses

   Relays receiving a response, first verify that the first URI in the
   To-Path corresponds to itself and if not, the response SHOULD be
   dropped.  Likewise if the message can not 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.)

   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, and the original request was a SEND
   request which 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.

   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 which corresponds to the next URI in the To-Path
   header.  If this connection has closed, then the response is silently

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

Jennings & Mahy         Expires December 23, 2005              [Page 18]

Internet-Draft                 MSRP Relays                     June 2005

   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
            / Byte-Range
            / Status
            / Authorization
            / 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

   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 Relays

   When resolving an MSRP URI which contains an explicit port number, an
   MSRP node follows the rules in section 6 of the MSRP base

Jennings & Mahy         Expires December 23, 2005              [Page 19]

Internet-Draft                 MSRP Relays                     June 2005

   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.

   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

   ;; 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 [1], Section 2.

   HTTP Basic authentication 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 main weakness of Basic
   authentication in MSRP is that "inner" relays can view the

Jennings & Mahy         Expires December 23, 2005              [Page 20]

Internet-Draft                 MSRP Relays                     June 2005

   credentials used to authenticate with "outer" relays.

   When multiple relays are under the administration of a single domain,
   this is unlikely to be a major problem.  MSRP was not designed to be
   used in the case where a client requires relays in more than one
   administrative domain to route traffic for its "end" of an MSRP
   session.  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.  Client
   should never be configured to send requests through such a 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 implement TLS.  Clients MUST send 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).  A relays 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.

   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

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 meets the broad

   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.

Jennings & Mahy         Expires December 23, 2005              [Page 21]

Internet-Draft                 MSRP Relays                     June 2005

   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
   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 administered to require 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: 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 its choice but relays must use TLS.  Clients must
   implement TLS.

Jennings & Mahy         Expires December 23, 2005              [Page 22]

Internet-Draft                 MSRP Relays                     June 2005

   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.

   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

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 an 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

Jennings & Mahy         Expires December 23, 2005              [Page 23]

Internet-Draft                 MSRP Relays                     June 2005


   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 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  \

   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.

12.  Acknowledgments

   Many thanks to Avshalom Houri, Miguel Garcia, Hans Persson, and Orit
   Levin, who 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.

Jennings & Mahy         Expires December 23, 2005              [Page 24]

Internet-Draft                 MSRP Relays                     June 2005

   [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.

   [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.

Jennings & Mahy         Expires December 23, 2005              [Page 25]

Internet-Draft                 MSRP Relays                     June 2005

   [18]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
         Message Session Relay Protocol",
         draft-ietf-simple-message-sessions-10 (work in progress),
         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

   Phone: +1 408 421-9990
   Email: fluffy@cisco.com

   Rohan Mahy

   Email: rohan@ekabal.com

Appendix A.  Implementation Consideration

   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 December 23, 2005              [Page 26]

Internet-Draft                 MSRP Relays                     June 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 portions of encrypted tokens to be cut and pasted into
   other URIs.

Jennings & Mahy         Expires December 23, 2005              [Page 27]

Internet-Draft                 MSRP Relays                     June 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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Jennings & Mahy         Expires December 23, 2005              [Page 28]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/